[uf-discuss] hCite progress

Ryan Cannon ryan at ryancannon.com
Mon Nov 13 09:20:29 PST 2006

I’ve been working on my resume this weekend, and have been
slopping together an hCite-ish beast for my publications. One thing
about type: I don't think this should be—or at least should have to
be—visible data. In most use cases that I can think of: a blogger
linking to another blog, a list of citations at the end of a
scholarly article, citation-hunting through a database, etc. The
difference between “article,” “book,” “incollection” and “conference”
are either not relevant or are implied by the types of data that the
citation contains. I’d much prefer to see:

     <cite class="article citation">...</cite>


     <cite class="citation"><span class="type">Article</span>: ...</ 

I’ll check over the wiki and make sure my citations match the proposal,
and be sure to post problems questions.



On Nov 13, 2006, at 11:40 AM, microformats-discuss- 
request at microformats.org wrote:

> Date: Mon, 13 Nov 2006 16:39:44 +0000
> From: "Brian Suda" <brian.suda at gmail.com>
> Subject: [uf-discuss] hCite progress


> 2) one of the manditory properties across several different citation
> formats is TYPE. Is this a Book, Journal entry, Thesis, Video, etc.
> Usually and enumerated list of values. The issue is that EVERYONE does
> it differently... so should hCite have an enumerated list of types
> such as "Thesis" and that maps to bibTeX "mastersthesis" and RIS
> "THES" or should that be something transforming apps handle. I'm not
> sure how to handle this (i'd prefer not to use enumerated lists of
> possible values) but if we allow open values, and i write <span
> class="type">Thesis</span> and that gets converted to a citation
> format, it will fail most of the formats because the string "Thesis"
> is not a valid type. I also think it is silly then to do <span
> class="type">THES</span> and then be valid for only one format. This
> is where a hard-coded list of values in hCite would help, hCite's
> "thesis" can be interpreted into various formats' TYPE values -
> although i don't like that idea, but don't have any other suggestions
> except to ignore it and let the implementor figure it out? Any
> comments?

More information about the microformats-discuss mailing list