citation-irc-notes-2006-04-09: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
No edit summary
Line 95: Line 95:
* I changed "number" to "issue". I also think that all of that content ought likely be moved out of the "container" wrapper into the root level. Finally, should not the container include another type class ("periodical" or "journal")? -- bruce
* I changed "number" to "issue". I also think that all of that content ought likely be moved out of the "container" wrapper into the root level. Finally, should not the container include another type class ("periodical" or "journal")? -- bruce
** I thought you wanted the model not to be flat, ie the container should have its own attributes? --alf
** I thought you wanted the model not to be flat, ie the container should have its own attributes? --alf
*** I am not referring to things like titles, but rather only to the locator information (volume, issue, pages), and this is primarily for practical reasons. Those in fact are not characteristics of the container (periodical), but rather of the relationship between the article and issue, and then the issue and the periodical. E.g. to model it "properly" would suggest three levels (root, container/issue, collection/periodical), each with their own respective locators. So I was just thinking for those reasons to in general say these locators ought to be associated with the root. What do you think? -- bruce
*** I am not referring to things like titles, but rather only to the locator information (volume, issue, pages), and this is primarily for practical reasons. Those in fact are not characteristics of the container (periodical), but rather of the relationship between the article and issue, and then the issue and the periodical. E.g. to model it "properly" would suggest three levels (root, container/issue, collection/periodical), each with their own respective locators. So I was just thinking for those reasons to in general say these locators ought to be associated with the root. What do you think? -- bruce. Why not do three levels? -- alf.
**** It might be useful to define which elements would appear at each level.  If there are "universals" that would appear in any of kind of citation (although might have a different label/connotation based on context), what would they be?  Title?  Creator?  What else?  Then we can start figuring out the special elements for each "type" of citation. --ross
**** It might be useful to define which elements would appear at each level.  If there are "universals" that would appear in any of kind of citation (although might have a different label/connotation based on context), what would they be?  Title?  Creator?  What else?  Then we can start figuring out the special elements for each "type" of citation. --ross
***** Titles is the obvious one that applies across the board: chapters, books, photographs, legal cases, court reporters, webpages, series, etc. all have titles. Likewise, they all have different kinds of contributors (including in many cases creators). But that's it I think.  -- bruce
***** Titles is the obvious one that applies across the board: chapters, books, photographs, legal cases, court reporters, webpages, series, etc. all have titles. Likewise, they all have different kinds of contributors (including in many cases creators). But that's it I think.  -- bruce
***** See the generic format above: title, creator and date are pretty universal. --alf


=== Additional elements for a book citation ===
=== Additional elements for a book citation ===

Revision as of 14:21, 11 April 2006

Summary

A citation microformat needs to cover four uses:

  1. full, bibliographic citations, eg "The Title Of An Article. Smith J. Journal Title (1987). 46:1; 23-35." This is the main citation microformat and should contain all the information necessary to locate the item and create a text citation in all the common formats (MLA, APA, etc).
  2. minimal, inline citations in text, eg (Smith, 1987). These generally link to an item in the bibliography using a fragment identifier.
  3. full, inline citations in text, eg following a blockquote.
  4. description of the current item/page, including title, creator, date etc.
  • I disagree with this last requirement (description of the current item/page). A citation is IMHO a reference to a work *somewhere-else*. It is a reference to a work from *another* work. This is quite a different case than a work describing itself. For info about a work in the work itself, see for example blog-description-examples. -Tantek
    • the SELF description was discussed in the meet-up. The idea behind encoding all the attributes for the current page/item was to allow OTHERS to extract citation data from your page for their own use. Why should i re-key all the data about the article if i can simple convert the article to a citation itself! This should require no additional work or fields - their will be no properties unique to the SELF that are already not expressed in the base citation microformat. -brian
      • I understand the desire to help automate this, but that means that it would be nice to have a transform from the self-description of a work, to a citation of the work. That transform doesn't necessarily have to be the identity transform, hence the last requirement shouldn't be a requirement. -Tantek
        • Your point that a citation is a reference to an outside source is right Tantek, but that doesn't mean that the description of self should be ANY different than that of an extraneous document, save for the fact that we call it a "citation." I think this may well have been why Ed bruoght up the idea of an hDC, where we end up thinking of hCite as more-or-less a sort of wrapper for other microformats (hCard, hCal, etc.). -Bruce
          • But we are not talking about "should be ANY different". We are talking about "should be SAME". My point is that it should NOT be a *requirement* for *citations* per se. The recognition that people will want to cite works is a good one, and thus when working on any "description" type format for a work describing itself, *that* work should look to the citation microformat and be sure to specify a transform, i.e. how to create a citation from a description. The easiest thing *might* be to simply embed a citation, but that is up to the description format, not up to the citation format, and thus should NOT be a requirement for the citation format. My guess is that most description formats will be a superset of what a general purpose citation has in it.
            • Consider the example of an article that contains within the page something along the lines of "Please cite this article as: The Title Of An Article. Smith J. Journal Title (1987). 46:1; 23-35.". That's both a citation and a description of the current page, and it should be marked up as such. --AlfEaton
              • Alf, that's a theoretical example, so we should not consider it as a requirement. If you can find 80/20 examples in the real world (published on the Web) that contain such a "suggested citation", please add those examples to citation-examples.
                • Sigh, this is all sounding a bit patronizing Tantek. It's not a "theoretical example"; just Google for the phrase "please cite this article." But I'll add an example or two to the examples page. -- bruce
  • In addition, naming a document "-recommendation" at this point is quite premature, especially when there is much work to be done in both doing the work and cleaning up of citation-examples, citation-formats, and citation-brainstorming. If this is meant to be a record of notes or a summary of a discussion, then it should be a notes page, e.g. see for example geo-bof-2005-06-30. Thanks, -Tantek
    • I will write-up the notes for the irc-meeting shortly and post them to the appropriate place. In the mean-time the general consenus was that we have closed on the exploration phase of the citation microformat. We have solid goals and are moving to implementation. Admittably the citation pages need some serious clean-up, but there is no need to halt progress in the development/itteration phase for those who are helping to move forward the format. -brian
      • Considering any "exploration" "closed" regarding a microformat makes no sense at all when the work to complete the necessary pages per the process has yet to happen. I'm moving this page to a name more reflecting of its consideration within the process, just notes. -Tantek

Current problems

  • Bibliographies published in HTML generally just use plain text (a URL is often included), but are sometimes produced from fully marked-up data, which is lost.
  • inline citations often link to bibliography items, but use named anchors rather than fragment identifiers.
  • There are multiple ways of adding self-descriptive data to web pages, such as meta tags -- with or without Dublin Core -- or embedded RDF.
    • meta tags are nearly useless since their content is invisible. -Tantek


Straw Proposals

These straw thoughts/proposals should be on the citation-brainstorming page, not here, along with some citation (so to speak ;) of the proposer. -Tantek

Microformat for inline citations

<cite>
<a href="#ref-1">1</a>
</cite>
<cite>
<a href="#ref-1">Smith, 2002</a>
</cite>


Microformat for a generic bibliography citation

<li class="citation" id="ref-1">
<span class="title">
 <a class="url" href="http://dx.doi.org/[DOI]">[item title]</a>
</span>
<span class="creator vcard">
 <span class="n">
  <span class="family-name">[surname]</span>, 
  <abbr title="[given-name]" class="given-name">[initial]</abbr>
 </span>
</span>
<span class="creator vcard">
 <span class="n">
  <span class="family-name">[surname]</span>, 
  <abbr title="[given-name]" class="given-name">[initial]</abbr>
 </span>
</span>
<abbr class="date-published" title="YYYY-MM-DDTHH:MM:SS+ZZ:ZZ">[year]</abbr>
</li>


Note: for an full inline citation, the

<li class="citation" id=""></li>

would be replaced by

<cite></cite>

and there would not be a link to a local fragment.


Note: for a self citation, the

<li class="citation" id=""></li>

would be replaced by

<span|div class="citation self"></span|div>


Additional elements for a journal article citation

class="citation article"
<span class="container">
 <span class="title">
  <a class="url" href="http://dx.doi.org/[doi]">[journal title]</a>
 </span>
 <abbr class="date-published" title="YYYY-MM-DDTHH:MM:SS+ZZ:ZZ">[year]</abbr>
 <span class="volume">[volume no.]</span>
 <span class="issue">[issue no.]</span>
 <abbr class="uri" title="urn:issn/[issn]"/>
</span>

<span class="pages">[start-page]-[end-page]</span>
<abbr class="uri" title="info:pmid/[PMID]"/>
  • I changed "number" to "issue". I also think that all of that content ought likely be moved out of the "container" wrapper into the root level. Finally, should not the container include another type class ("periodical" or "journal")? -- bruce
    • I thought you wanted the model not to be flat, ie the container should have its own attributes? --alf
      • I am not referring to things like titles, but rather only to the locator information (volume, issue, pages), and this is primarily for practical reasons. Those in fact are not characteristics of the container (periodical), but rather of the relationship between the article and issue, and then the issue and the periodical. E.g. to model it "properly" would suggest three levels (root, container/issue, collection/periodical), each with their own respective locators. So I was just thinking for those reasons to in general say these locators ought to be associated with the root. What do you think? -- bruce. Why not do three levels? -- alf.
        • It might be useful to define which elements would appear at each level. If there are "universals" that would appear in any of kind of citation (although might have a different label/connotation based on context), what would they be? Title? Creator? What else? Then we can start figuring out the special elements for each "type" of citation. --ross
          • Titles is the obvious one that applies across the board: chapters, books, photographs, legal cases, court reporters, webpages, series, etc. all have titles. Likewise, they all have different kinds of contributors (including in many cases creators). But that's it I think. -- bruce
          • See the generic format above: title, creator and date are pretty universal. --alf

Additional elements for a book citation

class="citation book"
<span class="container">
 <span class="title">
  <a class="url" href="http://dx.doi.org/[doi]">[book title]</a>
 </span>
 <span class="subtitle">[book subtitle]</span>
 <span class="publisher vcard">[publisher]</span>
 <span class="editor vcard">[editor]</span>
 <abbr class="date-published" title="YYYY-MM-DDTHH:MM:SS+ZZ:ZZ">[year]</abbr>
 <abbr class="uri" title="urn:isbn/[isbn]"/>
</span>

<span class="pages">[start-page]-[end-page]</span>

BDarcus: this looks good. I wonder, though, about two issues.

1. why not just title and abbreviatedTitle instead of title and subtitle?

2. date-published with books in particular is a can of worms. My book, for example, has a copyright date of 2006 (which is what one would include in the citation) but an actual publication date sometime in late-2005. The specificity of date-published is thus misleading. What we're really talking about is a copyright date. I wonder if the above might not be better with two classes: date and copyright? So then these classes of dates: date, copyright, issued (more generic than published). That slso fits dc and qualified dc.

  • This seems complicated (of course, it's all complicated) because there's an assumption that the citation creator will actually know which of these the date actually is. It seems like a generic date field that can be qualified with "published" or "copyright" or "actual year the conference happened", etc. would be more user-friendly.
    • Ross, yes, that's what I had in mind (but didn't explain very well). A generic "date" class ought to work for most cases, but leave room to add further qualfiers if necessary. -- bruce