citation-issues: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(moving "requirements" from brainstorming to issues.)
 
m (link)
 
(6 intermediate revisions by 3 users not shown)
Line 5: Line 5:
== Issues ==
== Issues ==


([http://microformats.org/wiki?title=citation-issues&diff=21777&oldid=15311 I have withdrawn the issues I submitted]. Feel free to resurrect them from the archive if you think anybody else is interested in them, but I will not be pursuing them further. --Thomas Breuel)


* Generally, use cases are used to flesh out requirements, but I don't see any on this page, so I've added a new section for thisHere are some suggested requirements. [[ThomasBreuel]]
===Convert citation formats===
*I've made these into issues. [[[[User:BenWest|BenWest]] 16:56, 8 Apr 2007 (PDT)]]
'''Should a user agent provide retransmission of a citation in a new format?  Which ones?'''
A user agent should be capable of reading a citation from a web page, in a given format, and converting it into a second format, for use elsewhere. For a list of such formats, and examples, see [http://en.wikipedia.org/wiki/Citation#Format_styles Wikipedia, Citation styles]. [[User:AndyMabbett|Andy Mabbett]] 11:05, 30 Mar 2007 (PDT)


* {{OpenIssue}}
== Outstanding Issues ==
===Lossless Round-Trip Conversions===  
Moved from [[citation-brainstorming]] by [[[[User:BenWest|BenWest]] 17:30, 8 Apr 2007 (PDT)]] available at http://microformats.org/wiki?title=citation-brainstorming&diff=0&oldid=15305
'''Should citation support roundtrip conversions? Which formats should be supported?'''
One of the primary uses for a citation format is to permit people to put individual citations or entire bibliographies on the web.  For that purpose, it's important that if someone puts up my bibliography on the web and someone else downloads it, they actually get back the citations correctly, and don't have to spend time fixing up the citations manually.  Therefore, I suggest the following requirement.


''If X is one of the common citation formats (BibTeX, EndNote, etc.), then conversion of the form X -> hCitation -> X must not lose information and must not require manual fixing up of the result.''
The 3 main points I (Brian) came across so far are:
# <span style="text-transform:uppercase;">identifiers</span>
# <span style="text-transform:uppercase;">format types</span>
# <span style="text-transform:uppercase;">nesting</span>


Note that this has multiple components. First, for a format like BibTeX, it's important that the field names be preserved. Second, in general, markup (italics, math, chemical formulas, spacing, special characters) needs to be preserved.
* {{OpenIssue}} '''How should different kinds of non-globally unique identifiers be represented?'''
1) In hCard/hCalendar there is a UID field. Added with URL it makes for a great unique identifier. There are loads of other identifers besides URL, ISBN, LOC call number, SKU, ISSN, etc. Many of these are unique in their domain, but not globally unique. So how to they get marked-up? Much like the hCard TEL/ADR properties, we can use something like:
<pre>
<nowiki>
<div class="uid"><span class="type">ISBN</span>: <span
class="value">123456</span></div>
</nowiki>
</pre>
This makes the encoding the most extensible... if we start use class="isbn" then it is an enumerated list, with class="type" it is open ended.


* {{OpenIssue}}
===Citation Markup=== '''Should citations preserve presentation?'''
Citations may contain markup, such as italics, subscripts, superscripts, special characters, and chemical formulas.  For a correct presentation of the citation format to the user, the format must permit even fairly complex markup.  Note that this markup cannot easily be converted automatically between different bibliographic processors.


* {{OpenIssue}}  
* {{OpenIssue}} '''What vocabulary should be used to distinguish between medium (aka format) versus type of work.  How do we resolve ambiguity between type of work and the publishing medium?'''
===Encapsulation of Non-Textual Content=== '''Should citations support non-textual content?'''
2) I keep mis-using "format", format is the medium - hardback, softback. The TYPE (there probably is a better word - container?) is book, article, conference, manifesto, etc. Much like the identifers we can make an enumerated list of values, class="book", class="article", but that boxes us in, whereas something like: <pre><nowiki><span class="type">article</span></nowiki></pre> leaves things more open.
Systems like document image processors need to be able to represent semantic roles of parts of pages without actually giving a usable textual representation. For example, a system might segment citations into authors, titles, volumes, and years, but represent the actual content of those fields using image tokens rather than characters. Furthermore, no text to put into an ABBR tag may be available


* {{OpenIssue}}
===No New Semantics=== '''Should citations avoid introducing new semantics?'''
The proposals for a citation microformat, as they now stand, suggest creating a new format that differs from existing formats not just syntactically, but semantically (different choices of field types than other formats, different handling of proper names, different handling of publications that are part of collections, etc.).  This has some serious consequences; in particular, it means that translation into any existing format is not just a simple syntactic transformation, it requires that an tools that deals with the citation microformat needs to be updated to handle new semantics, in addition to new syntax.  An alternative is to define one or more microformats that are strictly a syntactic transformation of existing formats (e.g., encapsulated BibTeX, encapsulated Endnote).


So, a possible requirement to consider is that citation microformats introduce no new semantics, but are a strict syntactic encapsulation of existing citation formats.
* {{OpenIssue}} '''Should citations support nesting?'''
3) Nesting citation data in a citation. The ability to nest the same microformat inside itself is something that other microformats don't explicitly handle.
 
The two options are:
i) Using class="book"
<pre>
<nowiki>
<div class="hcite">
<div class="book">
  <span class="fn">Book Title</span>
  <div class="chapter">
    <span class="fn">Chapter Title</span>
  </div>
</div>
</div>
</nowiki>
</pre>
 
This makes things easy to nest and to figure out exactly what is
associated with what, but the downside is that we have enumerated
lists of values for the class properties.
 
ii) using the TYPE for book
<pre>
<nowiki>
<div class="hcite">
<div class="type">book</div>
<span class="fn">Book Title</span>
<div class="type">chapter</div>
<span class="fn">Chapter Title</span>
</div>
</nowiki>
</pre>
 
now the class="fn" is not nested inside the class="book" or class="chapter" so there would have to be some other mechanism to associate the data with the type.
 
== Template ==
 
{{issues-format}}
 
==See also==
{{citation-related-pages}}

Latest revision as of 11:22, 14 January 2008

BenWest will start this by reorganizing material from http://microformats.org/wiki?title=citation-brainstorming&diff=0&oldid=15286.

Issues

(I have withdrawn the issues I submitted. Feel free to resurrect them from the archive if you think anybody else is interested in them, but I will not be pursuing them further. --Thomas Breuel)

Convert citation formats

Should a user agent provide retransmission of a citation in a new format? Which ones? A user agent should be capable of reading a citation from a web page, in a given format, and converting it into a second format, for use elsewhere. For a list of such formats, and examples, see Wikipedia, Citation styles. Andy Mabbett 11:05, 30 Mar 2007 (PDT)

Outstanding Issues

Moved from citation-brainstorming by [[BenWest 17:30, 8 Apr 2007 (PDT)]] available at http://microformats.org/wiki?title=citation-brainstorming&diff=0&oldid=15305

The 3 main points I (Brian) came across so far are:

  1. identifiers
  2. format types
  3. nesting
  • open issue! How should different kinds of non-globally unique identifiers be represented?

1) In hCard/hCalendar there is a UID field. Added with URL it makes for a great unique identifier. There are loads of other identifers besides URL, ISBN, LOC call number, SKU, ISSN, etc. Many of these are unique in their domain, but not globally unique. So how to they get marked-up? Much like the hCard TEL/ADR properties, we can use something like:


<div class="uid"><span class="type">ISBN</span>: <span
class="value">123456</span></div>

This makes the encoding the most extensible... if we start use class="isbn" then it is an enumerated list, with class="type" it is open ended.


  • open issue! What vocabulary should be used to distinguish between medium (aka format) versus type of work. How do we resolve ambiguity between type of work and the publishing medium?

2) I keep mis-using "format", format is the medium - hardback, softback. The TYPE (there probably is a better word - container?) is book, article, conference, manifesto, etc. Much like the identifers we can make an enumerated list of values, class="book", class="article", but that boxes us in, whereas something like:

<span class="type">article</span>

leaves things more open.


  • open issue! Should citations support nesting?

3) Nesting citation data in a citation. The ability to nest the same microformat inside itself is something that other microformats don't explicitly handle.

The two options are: i) Using class="book"


<div class="hcite">
 <div class="book">
  <span class="fn">Book Title</span>
  <div class="chapter">
     <span class="fn">Chapter Title</span>
  </div>
 </div>
</div>

This makes things easy to nest and to figure out exactly what is associated with what, but the downside is that we have enumerated lists of values for the class properties.

ii) using the TYPE for book


<div class="hcite">
 <div class="type">book</div>
 <span class="fn">Book Title</span>
 <div class="type">chapter</div>
 <span class="fn">Chapter Title</span>
</div>

now the class="fn" is not nested inside the class="book" or class="chapter" so there would have to be some other mechanism to associate the data with the type.

Template

Consider using this format (copy and paste this to the end of the list to add your issues; replace ~~~ with an external link if preferred) to report issues or feedback, so that issues can show up in hAtom subscriptions of this issues page. If open issues lack this markup, please add it.

Please post one issue per entry, to make them easier to manage. Avoid combining multiple issues into single reports, as this can confuse or muddle feedback, and puts a burden of separating the discrete issues onto someone else who 1. may not have the time, and 2. may not understand the issue in the same way as the original reporter.

<div class="hentry">
{{OpenIssue}} 
<span class="entry-summary author vcard">
 <span class="published">2011-MM-DD</span> 
 raised by <span class="fn">~~~</span>
</span>
<div class="entry-content discussion issues">
* <strong class="entry-title">«Short title of issue»</strong>. «Description of Issue»
** Follow-up comment #1
** Follow-up comment #2
</div>
</div>

See also