https://microformats.org/wiki/api.php?action=feedcontributions&user=RCanine&feedformat=atomMicroformats Wiki - User contributions [en]2024-03-29T07:09:11ZUser contributionsMediaWiki 1.38.4https://microformats.org/wiki/index.php?title=irc-people&diff=15397irc-people2007-04-03T23:46:33Z<p>RCanine: </p>
<hr />
<div>A list of [[irc|IRC]] regulars sorted by nick and their normal timezones (winter/summer).<br />
<br />
* [[User:Adam Craven|AdamCraven]] (+0000)<br />
* [[User:AmanuelTewolde|Amanuel]] (-0500/-0400)<br />
* [[User:Amette|amette]] (+1000)<br />
* [[User:Amir Guindehi|AmirGuindehi]] (+1000)<br />
* [[User:Ashley|Ashley]] (+1000)<br />
* [[User:B.K._DeLong|bkdelong]] (-0500/-0400)<br />
* [[User:Tyler Roehmholdt|Baristo]] (-0800/-0700)<br />
* [[User:Ben Ward|BenWard]] (+0000)<br />
* [[User:BenjaminCarlyle|BenjaminCarlyle]] (+1000)<br />
* [[User:HenriBergius|bergie]] (+0200/+0300)<br />
* [[User:BenWest|bewest]] (-0800/-0700)<br />
* [[User:BluesMoon|bluesmoon]] (+0530)<br />
* [[User:BobChao|BobChao]] (+0800)<br />
* [[User:Bob Jonkman|BobJonkman]] (-0500/-0400)<br />
* [[User:Boneill|boneill]] (+0000)<br />
* [[User:Brian|briansuda]] (+0000)<br />
* [[User:BryanRieger|Bryan Rieger]] (+0000)<br />
* [[User:Bug-E|Bug-E]] (+0200)<br />
* [[User:Cgriego|cgriego]] (-0600/-0500)<br />
* [[User:CharlesRoper|charles_r]] (0000/+0100)<br />
* [[User:Charlvn|Charl]] (+0200/+0200)<br />
* [[User:ChristopherStJohn|cks]] (-0600/-0500)<br />
* [[User:Cloud|Cloud]] (+0000)<br />
* [[User:Colin_Barrett|cbarrett]] (-1000)<br />
* [[User:ColinDDevroe|cdevroe]] (-0500/-0600)<br />
* [[User:Csarven|csarven]] (-0500/-0400)<br />
* [[User:DavidMead|DavidMead]] (-0400)<br />
* [[User:DerrickPallas|DerrickPallas]] (-0800/-0700)<br />
* [[User:Dan Kubb|dkubb]] (-0800/-0700)<br />
* [[User:DanC|DanC]] (-0600/-0500)<br />
* [[User:DannyAyers|danja]] (+0100/+0200)<br />
* [[User:Dave Cardwell|davecardwell]] (+0000)<br />
* [[User:DeanEro|deanero]] (-0800/-0700)<br />
* [[User:DiegoBudny|DiegoBudny]]<br />
* [[User:DimitriGlazkov|dglazkov]] (-0600/-0500)<br />
* [[User:DrewMcLellan|drewinthehead]] (+0000/+0100)<br />
* [[User:DrewBell|droob]] (-0600/-0500)<br />
* [[User:DimitriosZachariadis|dzach]] (+0200/+0300)<br />
* [[User:Ed Summers|edsu]] (-0500/-0400)<br />
* [[User:Enric|enric]] (-0800/-0700)<br />
* [[User:Enric|Enric]] (-0800/-0700)<br />
* [[User:Evan|evanpro]] (-0500)<br />
* [[User:ChrisMessina|factoryjoe]] (-0800/-0700)<br />
* [[User:Fil|Fil]] (+0200)<br />
* [[User:MarkNormanFrancis|Mark Norman Francis]] (+0000/+0100)<br />
* [[User:MarkoMrdjenovic|friedcell]] (+0100/+0200)<br />
* [[User:Grantbow|Grantbow]] (-0800/-0700)<br />
* [[User:HenrichPoehls|HenrichP]] (+0100)<br />
* [[User:Hlb|hlb]] (+0800-0700)<br />
* [[User:IanHickson|Hixie]] (-0800/-0700)<br />
* [[User:EdwardOConnor|hober]] (-0800/-0700)<br />
* [[User:Ichigo|ichigo]] (+1000)<br />
* [[User:IwaiMasaharu|iwaim]] (+0900)<br />
* [[User:Izo|IZO]]<br />
* [[User:JamieKnight|JamieKnight]] (+1000/0000)<br />
* [[User:WizardIsHungry|jcw9]] (-0500/-0400)<br />
* [[User:Adactio|Jeremy Keith]] (+0000)<br />
* [[User:JasonK|jkridner]] (-0600/-0500)<br />
* [[User:JoeGregorio|jcgregorio]]<br />
* [[User:Jonathan_Arkell|jonnay]] (-0700/0600)<br />
* [[User:JulianStahnke|Julian Stahnke]] (+0000)<br />
* [[User:Kapowaz|kapowaz]] (+0000/+0100)<br />
* [[User:Keri Henare|kerihenare]] (+1200)<br />
* [http://epeus.blogspot.com/ KevinMarks] (-0800/-0700)<br />
* [[User:RyanKing|kingryan]] (-0800/-0700)<br />
** [http://theryanking.com/blog/archives/2006/04/19/office-hours/ Office hours]: Wednesday, 21:00 UTC<br />
* [[User:Lachlan Hunt|Lachy]] (+1000/+1100)<br />
* [[User:Mark Mansour|Mark Mansour]] (+1100)<br />
* [[User:CiaranMc|McNulty]] (+0000/+0100)<br />
* [[mfbot]] - a bot which logs all edits to this wiki. It appends a number with a '+' or '-' sign, to indicate the number of characters added or removed as a result of the edit.<br />
* [[User:Mike|Michael McCracken(mmc)]] (-0800/-0700)<br />
* [[User:MikeKaply|mkaply]] (-0600/-0500)<br />
* [[User:SteveIvy|monkinetic/redmonk]] (-0700)<br />
* [[User:neuro|neuro`]]<br />
* [[User:NTollervey|ntoll]] (+0000/+0100)<br />
* [[User:Phae|Phae]] (+0000/+0100)<br />
* [[User:PriitLaes|plaes]] (+0200/+0300)<br />
* [[User:ChrisCasciano|pnhChris]] (-0500/-0400)<br />
* [[User:DavidOsolkowski|qid]] (-0500)<br />
* [[User:RCanine|RCanine]] (-0500/-0400)<br />
* [[User:Remi|Remi]] (-0500/-0400)<br />
* [[User:RobertBachmann|RobertBachmann]] (+0100/+0200)<br />
** Office hours: <del>Wednesday, 18:00-20:00 UTC</del> (Currently no office hours)<br />
* [[User:Ronnos|Ron Kok]] (+0000)<br />
* [[User:Dana Benson|Snowden]] (-0800/-0700)<br />
* [[User:Smackman|Steve Farrell]] (-0800/-0700)<br />
* [[User:Steve Ganz|SteveGanz]] (-0800/-0700)<br />
* [[User:SuperPhly|SuperPhly]] (-600/-500)<br />
* [[User:Tantek|Tantek]] (-0800/-0700)<br />
* [[User:Trovster|trovster]] (-0800/-0700)<br />
* [[User:Vant|vant]] (+0900)<br />
* [[User:KrissWatt|VoodooChild]] (+0000/+0100)<br />
* [[User:JacksonWilkinson|whafro]] (-0500/-0400)<br />
* [[User:Richard Conyard|WhiskeyM]] (+0000)<br />
* [[User:Veeliam|William Lawrence]] (-0800/-0700)<br />
* [[User:Ianloic|yakk]] (-0800/-0700)<br />
* [[User:StevenWoods|woodss]] (+0000 GMT)</div>RCaninehttps://microformats.org/wiki/index.php?title=governance-issues&diff=14493governance-issues2007-03-20T04:29:40Z<p>RCanine: /* Mailing List Unmoderation Discussion */</p>
<hr />
<div>== Issue Summary 2007-02-28 ==<br />
=== Editor ===<br />
[http://www.opendarwin.org/~drernie/ Ernest Prabhakar]<br />
<br />
=== Contributors ===<br />
*[[User:AndyMabbett|Andy Mabbett]]<br />
* ... Please add yourself.<br />
<br />
== Preamble ==<br />
Over the last year, a few people (AndyMabbett, JoeAndrieu, ErnestPrabhakar) have raised issues about how the Microformats wiki, mailing list, and community are governed. This page is here to discuss ideas for documenting, formalizing, and/or improving our collective governance.<br />
<br />
== Abstract ==<br />
Governance has [http://www.phac-aspc.gc.ca/vs-sb/voluntarysector/glossary.html been defined] as "the traditions, institutions and processes that determine how power is exercised, how citizens are given a voice, and how decisions are made on issues of public concern." In the context of Microformats, it covers:<br />
* Rules (both written and unwritten) expected of community members<br />
* Who the various Admins are<br />
* What powers Admins have<br />
* Rules for how/when Admins can/should use those powers<br />
* How to questioning/appealing a decision by an Admin<br />
* How to become an Admin<br />
* How to question/change any of these<br />
<br />
While not all of these need to be explicitly spelled out, a healthy community our size requires a broad shared understanding of these facts -- as well as acceptance of them as "legitimate."<br />
<br />
== Who Are Admins ==<br />
* 2007-01-04 raised by [[User:DrErnie|DrErnie]] on [[microformats-issues]], before this page existed, and moved from there<br />
*# ''As discussed in [http://microformats.org/discuss/mail/microformats-discuss/2007-January/008011.html], there exist various concerns about the lack of clarity regarding governance of the list, wiki, and the specifications themselves. While agree that there does need to be some form of strong leadership to preserve the integrity of the community, I agree with [http://microformats.org/discuss/mail/microformats-discuss/2007-January/008022.html Colin Barrett] when he said:''<br />
:::"I think there should be bit more visible superstructure around just who is in this "cabal". It seems to me like the Editors/Authors of the various specs form the majority it of it, but perhaps that should be made a bit more apparent, and the "powers" of an editor (essentially, the ability to veto changes to the wiki, it seems) outlined a bit and some information about how to become an editor (AFIACT, make numerous, quality edits to the Wiki that the other editors approve of)."<br />
:An entry has been added to the FAQ regarding [http://microformats.org/wiki/faq#Q:_Who_controls_microformats.3F Who controls microformats?].[[User:DrErnie|Dr. Ernie]] 08:48, 2 Feb 2007 (PST)<br />
<br />
== Mailing List Unmoderation Discussion ==<br />
Discussion from [[mailing-list-unmoderation]].<br />
<br />
* I'm glad to see this issue getting traction. However, I'm curious why Ernie's standing in the community is relevant to the issue of unmoderating Andy. Tantek, could you explain why that has been presented as an integral part of this decision making process? Clearly, personal clout always shapes one's ability to influence the community; however, I doubt it should be officially incorporated in these "proceedings". Shouldn't every member of the community have an equal hearing under whatever governance procedures we use? [[User:JoeAndrieu|JoeAndrieu]] 09:38, 19 Mar 2007 (PDT)<br />
<br />
:[http://microformats.org/discuss/mail/microformats-discuss/2007-March/009066.html Tantek also said]: "''Ernie, as someone who has made overwhelmingly positive contributions to the microformats community, IMHO the occasional OT post is reasonable'".<br />
* I believe the statement was added to give context to the appealing member of the community. i.e. Ernie is a long standing, good contributor, as opposed to someone new who has no experience with this particular community or someone who has had little or no interaction with the community until now, and also negates it being a personal statement (rather he is interested in community as a whole, instead of being a friend of the Andy and having a personal goal, for example). Basically, he is a person with a certain amount of credibility and trustworthiness. [[User:Phae|Phae]] 10:25, 19 Mar 2007 (PDT)<br />
* Agreed, Phae, Ernie is such a person and that is Tantek's point. But should one need to be a "friend of the court" to bring an action? That practice reinforces a culture of privilege that has historically proven antithetical to transparency and equality, both characteristics of good governance, IMO. It is great to see the powers-that-be responding to Ernie's request. It is also a bit frustrating that only those deemed meritorious by the peerage can call forth due process and that Andy's own efforts to speak on his behalf--referencing my previous request to do the same--were summarily dismissed by Tantek because they were "adversarial." Any robust governance should, IMO, work independent of privilege and be capable of addressing adversarial situations without arbitrary limits on the speech of those whose liberties are under challenge.--[[User:JoeAndrieu|JoeAndrieu]] 14:18, 19 Mar 2007 (PDT)<br />
** Point taken and appreciated, but this is the first incident to come to this kind of a situation where someone else has felt the need to step in, and just happened to also involve someone that is felt to be a member of good standing. I'd like to hope that if another member of the community had felt a similar way and had chosen to bring it up, that it would also have been dealt with in this open manner (and I'm sure this incident will be brought up in the future). Hopefully this incident will be a good test case to better structure future interactions with administration. I can't personally comment on Andy's own appeals. [[User:Phae|Phae]] 14:45, 19 Mar 2007 (PDT)<br />
**Agreed. The first efforts to work through a process like this are bound to be less than ideal. However, I'd like to get on the record two main points that appear problematic.<br />
# [http://microformats.org/discuss/mail/microformats-discuss/2007-February/008490.html my previous request to do the same] was not, in fact, dealt with in this open manner. Rather it decayed into a defensive debate about governance generally, leaving poor Andy stuck in moderated censure. Perhaps I'm not the most diplomatic sort, but the issue on the table is not about me. It is about Andy's continuing moderation. <br />
# The [[mailing-list-unmoderation|unmoderation wiki page]] for Andy is effectively a public hearing on Andy's standing and privileges in the community, especially with [http://microformats.org/discuss/mail/microformats-discuss/2007-March/009066.html Tantek's request] that no replies be sent to the email list on the topic. I find it particularly disturbing that Andy's efforts to contribute to that hearing have been [http://microformats.org/wiki?title=mailing-list-unmoderation&diff=14419&oldid=14416 repeatedly] [http://microformats.org/wiki?title=mailing-list-unmoderation&diff=14456&oldid=14454 dismissed] by Tantek (see the [http://microformats.org/wiki?title=mailing-list-unmoderation&action=history history] for a complete list). While It probably wasn't the best form for Andy to edit my comment directly, he should, IMO, have a way to voice his opinion on the matter. He's been threatened with a ban if he does so on the mailing list. Is there another venue that is more appropriate than the wiki page taking input and votes on his unmoderation?--[[User:JoeAndrieu|JoeAndrieu]] 20:19, 19 Mar 2007 (PDT)<br />
* Shouldn't this point be moot? According to the terms of the moderation, it will be lifted "if he successfully sends only topical / positive / improving email to the lists for one week." Once the week passed, this moderation ought to have been lifted automatically, and should not require a vote, right? --[[User:RCanine|Ryan Cannon]]<br />
<br />
== Examples ==<br />
''Note: This is not to take a position on whether or not any of these decisions were appropriate or inappropriate. Rather, the existence of these events demonstrates the need to document why and how such decisions were -- or should be -- made and/or appealed.''<br />
<br />
* Labelling microformats schema discussions as [http://microformats.org/discuss/mail/microformats-discuss/2006-March/003551.html off-topic]<br />
** Already covered by the [[microformats]] principles.<br />
* Issue rejection [http://microformats.org/discuss/mail/microformats-discuss/2007-February/008864.html governance]<br />
* Negative, PoV and derogatory edit summary content such as "[http://microformats.org/wiki?title=hcard-authoring&diff=13621&oldid=12276#Add_To_Address_Book_Links smelled of excessive political correctness worrying]" and "[http://microformats.org/wiki?title=to-do&curid=1110&diff=13989&oldid=13988&rcid=23801 removed non-productive comment]".<br />
** Removal of negative content from the wiki is not a negative. The Admins use their best judgment.<br />
*[[rejected-formats#Pavatar|listing of items as "rejected"]] when [http://microformats.org/discuss/mail/microformats-discuss/2007-January/008271.html requests for evidence of said rejection] reveal none.<br />
** Not every email can be answered, nor should anyone expect them to be. In this case the rejection is in the mailing list archives.<br />
* Despite an assurance that "all of the admins will be apropriately (sic) listed on the wiki page [http://microformats.org/discuss/mail/microformats-discuss/2007-February/008526.html]", the [http://microformats.org/wiki/faq#Q:_Who_controls_microformats.3F list given in FAQ] is prefaced with the qualifier "including".<br />
** Reference for assurance? No such assurance should ever have been given.<br />
* Removal of disputed edits / removal of negative content from the wiki<br />
**[http://microformats.org/wiki?title=mailing-list-unmoderation&diff=next&oldid=14416 mailing-list-unmoderation (16:12, 19 Mar 2007)]<br />
**[http://microformats.org/wiki?title=governance&curid=3084&diff=0&oldid=14390&rcid=24255 governance (12:50, 19 Mar 2007)]<br />
** [http://microformats.org/wiki?title=governance-issues&diff=14401&oldid=14396 governance-issues (14:55, 19 Mar 2007)]<br />
**[http://microformats.org/wiki?title=mailing-lists&curid=1297&diff=14391&oldid=14389&rcid=24254 mailing-lists (12:42, 19 Mar 2007)]<br />
<br />
== Proposal ==<br />
<br />
# Create a ''microformats-admin'' mailing list, for easily contacting all admins<br />
# Create a ''microformats-meta'' mailing list, moderated by a non-Admin, to capture discussions that do not fit into current lists, plus act as a "court of appeals" for Admin decisions.<br />
# Create and maintain a [[governance]] page that captures and describes<br />
* the identity of current Admins<br />
* how to contact them<br />
* the kinds of behavior warranting Admin intervention<br />
* how to appeal an Admin decision/action<br />
<br />
== Resources ==<br />
<br />
* http://www.shirky.com/writings/group_enemy.html</div>RCaninehttps://microformats.org/wiki/index.php?title=mailing-list-unmoderation&diff=14472mailing-list-unmoderation2007-03-20T04:25:42Z<p>RCanine: </p>
<hr />
<div>Andy Mabbett was [http://rbach.priv.at/Microformats-IRC/2007-01-04#T011730 moderated (rather than banned for a week) on 2007-01-04] on the microformats mailing lists at the time for both his frequent/excessive off-topic posts, and his ignoring of several warnings from admins to please stop doing so (see microformats-discuss archives for details). Ernie P. (a longstanding overwhelmingly positive contributor to the community) has [http://microformats.org/discuss/mail/microformats-discuss/2007-March/009063.html proposed unmoderating Andy at this point, 2007-03-19]. Please add your opinion at the end:<br />
* +1 Ernie P.<br />
* +1 David Janes<br />
* +1 Nic James Ferrier<br />
* +1 Tantek<br />
* +1 Scott Reynen<br />
* +1 Steve Ganz<br />
* +1 Joe Andrieu<br />
* +1 M. Jackson Wilkinson<br />
* +1 BenWest<br />
* +1 Chris Foote (Spike)<br />
* -0.5 Edward O'Connor (hober)<br />
* +1 Tim Whtie<br />
* +1 Ryan Cannon<br />
* ... add your opinion (+1 unmoderate, 0 no opinion, -1 keep moderated) and your name<br />
<br />
===Discussion===<br />
Moved to [[governance-issues#Mailing_List_Unmoderation_Discussion|a section on the governance issues page]].</div>RCaninehttps://microformats.org/wiki/index.php?title=hcard-issues&diff=13098hcard-issues2007-01-31T20:00:07Z<p>RCanine: /* Issues */</p>
<hr />
<div><h1> hCard issues </h1><br />
<br />
These are externally raised issues about [[hcard|hCard]] with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec. <br />
<br />
'''IMPORTANT''': Please read the [[hcard-faq|hCard FAQ]] ''before'' giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.<br />
<br />
Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/log/ Tantek]<br />
<br />
Please add new issues to the '''top''' of the list.<br />
<br />
For matters relating to the vCard specification itself, see [[vcard-errata]] and [[vcard-suggestions]].<br />
<br />
See also related [[hcalendar-issues]].<br />
<br />
__TOC__<br />
<br />
== Issues ==<br />
<br />
<br />
* {{OpenIssue}} 2007-01-30 raised by [[User:AndyMabbett|Andy Mabbett]]<br />
*# Many sites, not least Wikipedia, publish co-ordinates as degrees-minutes-seconds (e.g. [http://en.wikipedia.org/wiki/Birmingham]). Should [[geo]] be extended to allow for this, with parsers making the conversion to digital values? <br />
* 2007-01-26 raised by James Craig on [[accessibility]] page.<br />
*# ''Localization of RFC2426 'type' values. RFC2426 type values for adr, email, and tel were intended as machine-readable values. Used as real HTML content in the following example only works in English. The accessify forum discussion described on the [[accessibility]] page has asserted that reducing this problem to an abbr is not a valid, accessible solution.''<pre><nowiki><br />
<span class="tel" xml:lang="en"><br />
<span class="type">Home</span> (<span class="type">pref</span>erred):<br />
<span class="value">+1.415.555.1212</span><br />
</span><br />
</nowiki></pre> ''Use the the class attribute for qname prefixed type values (and others such as dtstart values), AKA meta classes.'' <pre><nowiki><br />
<span xml:lang="en"><br />
Home (preferred): <span class="tel type:home type:pref">+1.415.555.1212</span><br />
</span><br />
<span xml:lang="es"><br />
Casa (preferido): <span class="tel type:home type:pref">+1.415.555.1212</span><br />
</span><br />
</nowiki></pre><br />
*#* REJECTED DUPLICATE ETC. Class attributes for type values [http://microformats.org/wiki/hcard-parsing#ISSUE_2 was tried and rejected] and in addition, [[qnames-considered-harmful]].<br />
<br />
* {{OpenIssue}} 2007-01-22 raised by [[User:Christina Hope|Christina Hope]].<br />
*# ''What is the easiest way to display an hCard all on one line with spacing. Currently I am using this - but I know that there has to be an easier/ simpler way to do it. <br/>Examples: (1) <pre><nowiki><p><br />
<span class="vcard"><br />
<span class="fn">Christina Hope</span>& nbsp;& nbsp;& nbsp;<br />
<span class="department">Information Technology</span>& nbsp;& nbsp;& nbsp;<br />
<span class="role">Website Coordinator</span>& nbsp;& nbsp;& nbsp;<br />
<span display="none" class="region"></span><br />
<span class="tel"> x3408</span> & nbsp;& nbsp;& nbsp;<br />
<span class="email"><a href="mailto:chope@example.com">chope@example.com</a></span><br />
</span></p></nowiki></pre>''<br />
<br />
:: Try <pre><nowiki><p class="vcard"><br />
<span class="fn">Christina Hope</span><br />
<span class="department">Information Technology</span><br />
<span class="role">Website Coordinator</span><br />
<abbr class="tel" title="+44123 456 7890 x 3408"> x3408</abbr><br />
<a class="email" href="mailto:chope@example.com">chope@example.com</a><br />
</p></nowiki></pre><br />
<br />
::Note: apply classes to existing elements; use abbr to give the phone number in full, in international format. Also, use CSS, not non- breaking spaces, for spacing.<br />
<br />
::[[User:AndyMabbett|Andy Mabbett]] 08:34, 22 Jan 2007 (PST)<br />
<br />
* {{OpenIssue}} 2006-12-15 raised ([http://microformats.org/discuss/mail/microformats-discuss/2006-December/007730.html on 2006-12-14, on the mailing list]) by Joe Andrieu.<br />
*# (Paraphrased) By including organisations and places, as well as people, hCards have lost semantic specificity (see cited mailing list post for details).<br />
<br />
* 2006-12-15 raised by [[User:WizardIsHungry|WizardIsHungry]]<br />
*# ''[Moved from a user talk page] Hey, why is hiding semi-useful information using CSS bad? The Geo and Address stuff wouldn't be enough to contact me, but I would like there so bookmarklets, crawlers, greasemonkey etc can manipulate it. Is there a policy on using CSS hiding of fields? Thanks :)''<br />
*#* I guess we can't rely that anything that consumes hCards is normalizing it to a particular format instead of just taking all the xml inside the hcard classed block and sticking it somewhere. If it does just store it as a string, then generating html from it will yield the same hidden fields. Perhaps hiding fields by applying a stylesheet to the relevant hcard styles is ok, but not hiding them using in-line CSS styling. Feedback? --[[User:WizardIsHungry|Jon Williams]] 10:28, 22 Dec 2006 (PST)<br />
*#* Furthermore, [[hcard-example1-steps]] shows using inline CSS to hide fields. What gives? I still think this is an open issue; particularly the distinction between external stylesheet hiding and inline rules though. --[[User:WizardIsHungry|Jon Williams]] 13:33, 5 Jan 2007 (PST)<br />
*#* Should this be on [[microformats-issues]]? --[[User:WizardIsHungry|Jon Williams]] 13:37, 5 Jan 2007 (PST)<br />
*#** The example you cite is the first of several steps, which refine and improve the first step's suboptimal hCard.<br />
*#*** The question is: ''why is this considered suboptimal if it is ok to hide the entire card?'''<br />
*#**** REJECTED CLOSED TOO THEORETICAL. It is not OK to hide the entire card. Without further concrete examples with real world URLs on the web, this issue is closed.<br />
*#***** Here are a number of examples of hiding the entire card, taken from [[hcard-examples-in-wild]]: [http://www.meryl.net/] [http://www.fberriman.com/] [http://www.fberriman.com/] [http://www.last.fm/user/Crok/?scrobbling=t1] -- Could someone link to where this was discussed and decided in the past, as it seems like this is being governed by fiat. Even if you don't care to have consensus, but could you at least justify this? This stonewalling is rather rude. --[[User:WizardIsHungry|Jon Williams]] 13:24, 9 Jan 2007 (PST)<br />
*#* [[hcard-brainstorming#CSS_Styles]] explicitly permits this. I'm going with what they say.<br />
<br />
* {{OpenIssue}} 2006-12-07 raised by RyanKing.<br />
*# ''hCard org-fn matching should use organization-name, if given.''<br />
*# originally [http://microformats.org/discuss/mail/microformats-discuss/2006-November/007337.html raised on uf-discuss] by David Janes.<br />
<br />
* {{OpenIssue}} 2006-11-24 raised by [[User:AndyMabbett|Andy Mabbett]]<br />
*# A suggested work-around for the lack of a gender property is to represent gender implicitly in the honorific-prefix field, e.g. Mr. for male, and Ms. for female. This approach does has the limitation that "Mr." and "Ms." (or "Miss"/ "Mrs.") conflicts with a higher-ranking, gender-neutral honorific, such as "Dr." or "Rev." for the person, as it is unusual (and sometimes, outside the USA, invalid) to refer to someone as "Mr. Dr." or "Mrs. Rev." for example. Note also that some cultures or religions regard such titles as offensive, or at least disdain them.<br />
<br />
* 2006-11-23 raised by [[User:AndyMabbett|Andy Mabbett]]<br />
*# The specification should be "stand alone", and not normally require reference to the vCard specification.<br />
*#*A: ACCEPTED PARTIAL. Agreed that [[hcard|hCard]] should be usable by typical web authors without having to dig through the vCard specification. Precise implementation of parsing etc. hCard properties however will likely require programmers to reference the specifics/grammars in the vCard specification which we will NOT replicate in the hCard specification in order to avoid inevitable introduction of errors due to duplication. And that being said, ''informative'' explanations may be a good idea, while the vCard property/value definitions are kept as ''normative''.<br />
*#** Yes; my meaning was with reference to hCard publishing, not parsing-into-vCards. [[User:AndyMabbett|Andy Mabbett]]<br />
*# ''The specification should state that "telephone numbers SHOULD adhere to [http://en.wikipedia.org/wiki/E.123 ITU-T Recommendation E.123]" (or perhaps "MUST").''<br />
*#* ACCEPTED PARTIAL. This makes sense as an informative reference and a MAY, but since vCard makes no such SHOULD statement for TEL values, neither should/will hCard. In addition, as a Wikipedia URL that is subject to drastic change, we cannot make that a normative reference.<br />
*#** I take your point about Wikipedia - here's [http://www.itu.int/rec/T-REC-E.123-200102-I/en a more definitive ITU-E.123 URL]; but it's for a chargeable document. Using "SHOULD" or "MUST" in hCard will not affect compatibility with or conversion to vCard. [[User:AndyMabbett|Andy Mabbett]]<br />
<br />
* 2006-11-16 raised by [[User:AndyMabbett|Andy Mabbett]]<br />
*# ''The "type" for "tel" lacks a "textphone" option (for the devices used by, e.g., people who are deaf or have speech difficulties. Example: [http://www.birmingham.gov.uk/contact Birmingham City Council (303 1119)].''<br />
*#*A: REJECTED. This is a vCard issue, as the "type" taxonomy for "tel" is determined by vCard. We are not presently extending hCard beyond the properties and values in vCard.<br />
*#** ''I'm not clear how you can "reject" a provably factual statement. What's the process of suggesting an update to vCard? [[User:AndyMabbett|Andy Mabbett]]''<br />
*#***A: ACCEPTED PARTIAL RESOLVED. Unfortunately it is not clear what the process is for updating vCard. However, we can at least capture suggestions for improvement to vCard from this community which may be helpful once the process for updating vCard is understood. I've created [[vcard-suggestions]] for this purpose and added this suggestion. - Tantek <br />
*#**** The vCard spec is updated by RFC, for example [http://www.rfc-editor.org/rfc/rfc4770.txt RFC 4770]. [[User:AndyMabbett|Andy Mabbett]] 06:22, 12 Jan 2007 (PST)<br />
<br />
* {{OpenIssue}} 2006-10-21 raised by [[User:AndyMabbett|Andy Mabbett]]<br />
*# ''There should be some way to say that the URL of an hCard or hCalendar event is the URL of the page itself, without having to include a redundant, and accessibility-damaging link to that page, on the page itself.''<br />
<br />
* 2005-06-21 raised by Hixie<br />
*# ''Issue H-1: This specification is lacking a user agent conformance section. There's basically nothing that says how hCards must be parsed, how to handle errors, and so forth. Is it defined in terms of the DOM? Is it defined in terms of a serialisation? How do you handle unexpected content or missing content?<br />
*#*A: ACCEPTED RESOLVED. See [[hcard-parsing]] for how hCards must be parsed. For errors/unexpected content/missing content, please provide specific examples.<br />
<br />
* 2005-06-30 raised by Jack L. Wolfgang II. Please feel free to move these to the FAQs if they are better suited there.<br />
*# ''Handling middle names and suffixes: How does one handle middle initials/names in the hCard format and suffixes that are not honorific suffixes (e.g. Jr., Sr., II, III, etc. as opposed to Ph.D., Esq., M.D., etc.)?''<br />
*#*A: ACCEPTED FAQ. By [http://suda.co.uk Brian Suda] (2005-11-08 updated by [http://tantek.com/log/ Tantek]; 2006-11-16 updated by [[User:AndyMabbett|Andy Mabbett]]) hCard is based of the RFC2426 spec. I you want to use a middle initial it can be expanded using the abbr element. <code>&lt;abbr title="[MiddleName]" class="additional-name"&gt;M&lt;/abbr&gt;</code>. Honorific Suffixes in the RFC include Jr., Esq. and other inherited suffixes, so I would just use <code>&lt;abbr class="honorific-suffix" title="Junior"&gt;Jr.&lt;/abbr&gt;</code> etc.<br />
*# ''Handling different types of addresses: How does one handle the TYPE (e.g. postal, work, etc.) specification for addresses as specified in RFC 2426 Section 3.2.1?''<br />
*#*A: ACCEPTED FAQ. By [http://suda.co.uk Brian Suda] (2005-11-08 updated by [http://tantek.com/log/ Tantek]) If you want to add a type to certain elements, including address and telephone it may be done in the following manner:<br />
<pre><nowiki><br />
&lt;span class="adr"&gt;<br />
&lt;span class="type"&gt;work&lt;/span&gt;:<br />
...<br />
&lt;/span&gt;<br />
</nowiki></pre><br />
<pre><nowiki><br />
&lt;span class="tel"&gt;<br />
&lt;span class="type"&gt;work&lt;/span&gt;:<br />
&lt;span class="value"&gt;123.456.7890&lt;/span&gt;<br />
&lt;/span&gt;<br />
</nowiki></pre><br />
the TYPE needs to be a sub-element of the property (adr, tel, etc) NOTE: EMAIL does NOT have many TYPE attributes, only INTERNET and X400<br />
<br />
* {{OpenIssue}} 2006-04-10 raised by [[User:ScottReynen|Scott Reynen]].<br />
*# ''When someone looks at the [[hcard|hCard]] pages, one sees no collection of real-world publishing of contact data nor discussion of the properties implied by such examples, I think it's far too easy to infer that microformats come from other formats more than actual behavior. There's nothing on the [[process]] nor the hcard pages explaining this discrepancy. I would argue that there should be an explanation, probably in both places.''<br />
<br />
* 2006-04-06 raised by [[User:Evan|Evan]].<br />
*# ''What is the relationship between the CATEGORY property and [[rel-tag]]? Can you add a tag to an hCard? How can you add a tag to a particular hcard on a page without tagging the other cards on a page?''<br />
*#* ACCEPTED. Categories can optionally be represented as tags. The classname 'category' should always be used, but rel="tag" can optionally be used (in addition to the category classname). In the case that a rel-tag tag is used, the tag (as defined by [[rel-tag]]) is used for the category. Examples: (1) <code><nowiki><span class="category">food</span></nowiki></code> and (2) <code><nowiki><a class="category" rel="tag" href="http://example.com/food">Food!</a></nowiki></code>. --[[User:RyanKing|RyanKing]] 15:16, 13 Jun 2006 (PDT)<br />
<br />
* {{OpenIssue}} 2006-03-07 raised by [http://tantek.com Tantek].<br />
*# ''Issue 1: In 99% of the cases I am finding the need to explicitly do "n" markup, the person has a three word fn which is in the form "given-name additional-name(or initial) family-name". Should we make three word fn's into another shorthand notation to make this easier for authors?''<br />
<br />
* 2006-02-23 raised by [http://www.thefutureoftheweb.com/ Jesse Skinner] and [http://www.thefutureoftheweb.com/blog/2006/1/hcard#comment1 Ben Buchanan].<br />
*# ''Are multiple URLs allowed? The [http://microformats.org/wiki/hcard#Property_List Property List] suggests not, whereas email and tel have multiple type/value pairs. However, the [http://microformats.org/wiki/hcard-parsing#finding_hCard_properties parsing page] suggests multiple URLs are OK. Either way, it seems clear that a type cannot be associated with a URL. So how exactly does hCard deal with multiple URLs?''<br />
*#* RESOLVED FAQ: Multiple URLs are allowed. Some consuming agents (Apple's AddressBook.app among them) don't have an interface for producing multiple URLs, but they are still valid in vCard and therefore hCard. --[[User:RyanKing|RyanKing]] 17:58, 12 Jun 2006 (PDT)<br />
<br />
* 2006-02-19 raised by Miika Mäkinen.<br />
*# ''Couldn't the types for tel numbers be specified in a class? Now, for a phone number one needs to add the type as "visible" text, which is not always preferred. For example, type "Work", many times more suitable label could be "Office" or similar and sometimes you might not want to display any type information at all.''<br />
*#* REJECTED TRIED ALREADY. Using class names for the "type" of a tel or adr [http://microformats.org/wiki/hcard-parsing#ISSUE_2 was attempted], and failed in many situations. In addition, the "type" information is actual data, not just a property name, and thus deserves to be in the ''visible'' markup. Note that you can use abbreviations, e.g. <code><nowiki><abbr class="type" title="work">W:</abbr></nowiki></code> in order to present the type in a way that may better fit in with the rest of your presentation.<br />
<br />
* 2006-02-13 raised by [http://microformats.org/wiki/User:Eron_Wright Eron Wright]<br />
*# ''Few systems contemplate the altitude component of a coordinate, yet it exists. Altitude becomes important when working with 3D mapping software such as Google Earth. Indeed, the geocoding service that Google Earth uses returns a three-dimensional coordinate. I suggest that hCard provide explicit support for altitude.''<br />
*#* REJECTED POSTPONED. Not in vCard. There is no "altitude" component in vCard (RFC 2426), and thus (certainly for now) there won't be any in hCard. If a new version of vCard were to come out with altitude, then we would add it to hCard. At some point we may also consider adding explicit extensions beyond vCard, but if we were to do so, we would capture them first on the [[hcard-brainstorming]] page.<br />
<br />
*2006-02-03 raised by Brian<br />
*# We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element<br />
<br />
* {{OpenIssue}} 2006-01-28 raised by [http://rbach.priv.at/Microformats-IRC/2006-01-28#T075222 Tantek on #microformats]<br />
*# ''Is hCard is really appropriate for a named phone bridge, or do we need something else for a named phone numbers that are neither people nor organizations (the current two precise semantics that can be defined by hCard). For example see the "Zakim" hCard on http://www.w3.org/2005/12/allgroupoverview.html''<br />
<br />
* 2006-01-21 raised by [http://inspire.server101.com/ben/resume/ Ben Boyle].<br />
*# ''Have run into issues trying to use definition lists with hCard, specifically around nesting requirements for tel where the DT element takes a class "type" (e.g. Telephone, Facsimile) and the DD element marks the value. It is invalid to place any other elements within a DL that wrap around the DT/DD pairs so there is no available element to assign the class "tel" to. XHTML2 proposes a DI element that will resolve this issue. I am hoping for an interim solution for those that wish to use definition lists, perhaps that "any class that would be placed on the DI parent (in XHTML2) must instead be placed on the first DT element". I realise this will cause headaches for those implementing hCard parsers. I'd also like to note this may affect other (current or future) microformats and relates to the general hassle of definition lists in current (X)HTML recommendations. For your consideration - thanks!''<br />
*#* REJECTED WORKAROUND AVAILABLE. Either don't use definition lists in this manner (because the description of a definition should go completely in the DD element, and thus you should be able to put the class on that), or use separate DLs in the cases where you would otherwise have needed a DI element.<br />
<br />
* 2005-12-08 raised by [http://www.heatonarts.com Kenny Heaton].<br />
*# ''The specification gives no way to to declare a telephone extension, as in (800) 234-5678 ext. 101''<br />
*#* ACCEPTED FAQ. What is the best way to declare a telephone extension in a "tel" property? (also seems like it would be a vCard FAQ).<br />
<br />
* 2005-10-30 raised by [http://greenbytes.de/tech/webdav/ Julian Reschke].<br />
*# ''Several implementations'' '''(Which ones? Please provide links.)''' ''seem to assume that any class attribute that contains the substring "vcard" indeed signals the presence of vcard information. Not so: there are examples'' '''(What examples? Please provide links.)''' ''of where a token in the class attribute indeed only ''starts with'' "vcard", in which it should be ignored. Implementations using XPath (such as XSLT or Greasemonkey scripts) should be advised to do a <code>contains(concat(@class,' '),'vcard ')</code>.<br />
*#* REJECTED VAGUE. Which implementations? And which examples?<br />
*#*''(Note: the code <code>contains(concat(@class,' '),'vcard ')</code> is broken see [[parsing-microformats#Parsing_class_values]] for a correct example --[[User:RobertBachmann|Robert Bachmann]])''<br />
<br />
* 2005-08-12 raised by [http://home.alltel.net/jackwolfgang/contact/ Jack L. Wolfgang II]. Use of mailto transport functionality for the E-Mail address field.<br />
*# ''As stated in the [[hcard-brainstorming]] document, mailto is abused by spammers. As a result, many organizations have moved to form-based contacts as opposed to mailtos. According to [http://www.ietf.org/rfc/rfc2426.txt RFC 2426], Section 3.3.2, "A non-standard value can also be specified." Does this refer to a non-standard e-mail address value or type value?''<br />
*#* A: ACCEPTED FAQ. Type value.<br />
<br />
* 2005-07-23 raised by DanConnolly<br />
*# ''Are class names case sensitive or not? [[hcard]] says "If names in the source schema are case-insensitive, then use an all lowercase equivalent."''<br />
*#* A: ACCEPTED FAQ. Class names are case sensitive per the HTML4 specification. Hence hCard explicitly specifies the case of class name to use for source schema names that are case-insensitive.<br />
*# ''...but I find example data with class="Given-Name"''<br />
*#* A: ACCEPTED RESOLVED. That is from an older preliminary version of the hCard spec which used mixed case class names. Such class names are no longer valid hCard. Please note which examples (URLs) are using the older class names and hopefully we can get them fixed.<br />
*#** A: By [http://suda.co.uk Brian Suda] I have fixed all the references in the [[hcard-brainstorming]] page to reflect the lower-case style, this is a hold-over from the original design, X2V has been updated.<br />
*# ''..and code that supports it [data with class="Given-Name"].''<br />
*#* A: ACCEPTED RESOLVED. Any code supporting the older class name(s) is for backward compatibility only, and should be phased out. Any new hCard code SHOULD NOT support such mixed case class names.<br />
*#** [http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html rfc2629xslt.html] uses Street-Address, Family-Name, etc.<br />
*#*** A: By [http://greenbytes.de/tech/webdav/ Julian Reschke] Fixed rfc2629.xslt (2005-10-29)<br />
*#** [http://suda.co.uk/projects/X2V/ X2V] Version 0.5.1 2005-07-08 supports Family-Name etc.<br />
*#*** A: By [http://suda.co.uk Brian Suda] I agree that the upper-case class names can be removed from the code, this was a hold-over and will be trimmed.<br />
*# ''The ul/ol stuff for multiple values of a property seems to be in the X2V code and in [[hcard-brainstorming]] but not in the [[hcard]] spec.''<br />
*#* A. ACCEPTED RESOLVED. This needs to be added to the spec. 2005-11-08 Update: the way multiple values has been updated to work much better and not require ul/ol.<br />
*# ''the [[hcard-profile]] says country-name but X2V and lots of the data I've seen says country''<br />
*#* A. ACCEPTED RESOLVED. RFC 2426 clearly says "country name" in both the prose and the grammar, thus "country-name" is the correct class name to use. If X2V uses just "country", it needs to be fixed to use "country-name", and any such examples as well. Please note which examples (URLs) are using the class name "country" and hopefully we can get them fixed.<br />
*#** A: By [http://suda.co.uk Brian Suda] I have fixed all the references in the [[hcard-brainstorming]] page to reflect the proper country-name, X2V will support this in the next iteration when i fix several bugs at once.<br />
<br />
* 2005-07-22 raised by DanConnolly<br />
*# ''...in my cellphone/sidekick address book, I have a number of entries for companies. I wrote [http://dev.w3.org/cvsweb/2001/palmagent/asHCard.xsl asHCard.xsl] to convert the data from RDF to hCard, but I don't know what to do with entries for companies, since FN is mandatory in hCard.''<br />
*#*A: ACCEPTED FAQ. This should be an FAQ. "How do I write an hCard for a company?" The vCard specification is silent on this point (entries for companies). Thus there are two options as far as the hCard standard is concerned:<br />
*#*# Set "fn" and "org" to the same value. E.g. <code>&lt;span class="fn org"&gt;W3C&lt;/span&gt;</code> (recommended)<br />
*#*# Set "org" as usual, and set "fn" explicitly to empty. E.g. <code>&lt;span class="fn"&gt;&lt;/span&gt;&lt;span class="org"&gt;W3C&lt;/span&gt;</code> or<br />
*#*#* Simply have no "fn", and on the parsing side, if there is no "fn" present, but there is an "org" property, then duplicate the "org" value as "fn"<br />
*#*The last two options are effectively the same and are both not explicit and easily confusable with a "missing data" condition. Thus option 1 is preferred. For converting applications (hCard to vCard), they ''may'' consider using proprietary extensions to make the distinction explicit in generated vCards, based on either case 1 or 2 above. E.g. Apple's Address Book application supports the property: <code>X-ABShowAs:COMPANY</code><br />
*#*We are looking for descriptions of how other vCard supporting applications treat "company" vCards differently from "person" vCards. Please provide descriptions here:<br />
*#** Address Book / MacOSX.3:<br />
*#*** Export (e.g. drag & drop to desktop, view in text editor)<br />
*#**** Sets "FN" and "ORG" to the name of the company<br />
*#**** Sets proprietary <code>X-ABShowAs:COMPANY</code><br />
*#*** Import (e.g. edit in text editor, drag & drop from desktop)<br />
*#**** By setting "FN" and "ORG' to the same name (e.g. Banana Computers Inc.)<br />
*#**** And removing any proprietary properties (e.g. X-ABShowAs)<br />
*#**** Address Book user interface showed new vCard as a "company" contact rather an a person<br />
*#** Address Book MacOSX.4:<br />
*#*** same results as above -RyanKing<br />
*#** The Danger Hiptop (aka T-Mobile Sidekick) address book:<br />
*#*** Export (e.g. [http://lists.w3.org/Archives/Public/www-archive/2005Sep/0007.html email to a mailing list])<br />
*#**** Sets "FN" to the empty string and puts the company name in "ORG".<br />
*#*** Import - could not find a way to import a .vcf, by email, IM, or other means into the Sidekick.<br />
*#** Contacts / Outlook 2003 Windows<br />
*#*** Export (e.g. Highlight contact, File, Save As, vcard)<br />
*#**** Sets "N" and "ORG to the name of the company<br />
*#**** Sets "FN" to value in "File as:"<br />
*#** Add another vCard app here.<br />
<br />
=== Canonical/Authoritative Hcard ===<br />
<br />
* {{OpenIssue}} 2006-01-23 raised by David Janes (?).<br />
* ''Issue 1: Specifying Authoritative or Canonical or Official Hcard''<br />
** Use of rel="me" only specifies an alternate version, not necessarily the canonical version<br />
** Suggestion: use rel="me self". Adopt "self" semantics from Atom which means "the", or controversially "alternate, equivalent" version<br />
*** The combined use of rel="me" and rel="self" may conflict with their definitions in the [http://www.gmpg.org/xfn/11#me XFN Profile] and RFC 4287 respectively. See [http://microformats.org/discuss/mail/microformats-discuss/2007-January/008443.html the mailing list discussion on rel="me self"] for more information. From [[User:RCanine|Ryan Cannon]].<br />
** Suggestion: use rel="via". Per RFC 4287, via "signifies that the IRI in the value of the href attribute identifies a resource that is the source of the information provided in the containing element." from [[User:RCanine|Ryan Cannon]].<br />
** Other suggestions? "authoritative", "canonical"?<br />
** Problems with this suggestion?<br />
** How does this relate to authentication/trust issues? Is this a different problem with a different scope?<br />
*** (microformats-discuss list) Joe Andrieu: The concept behind an "authoritative" hCard rather than "definitive" or "canonical" one was that "authoritative" would explicitly be a /claim/ by the author of the hCard regarding its authority in describing the subject of the hCard, i.e., use /this/ hCard as the one true source of this individual's contact information.<br />
*** To summarize: authentication/trust is a separate topic.<br />
** What exactly is the scope of the problem to solve here?<br />
*** (IRC) (10:47:44) sreynen: for example, all of the examples i've seen involve a single person publishing multiple hCards of himself<br />
*** (IRC) (10:48:13) sreynen: yet many people are talking about 3rd parties publishing hCards and pointing back to the subject's own hCard<br />
** rel="me" must be symmetrical, per the XFN spec. What exactly does this mean for this use?<br />
<br />
''TODO:'' please add apropriate context and history of this issue from the mailing list. Sign your name to your comments.<br />
<br />
== Template ==<br />
<br />
Please use this format (copy and paste this to the end of the list to add your issues):<br />
* {{OpenIssue}} YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].<br />
*# ''Issue 1: Here is the first issue I have.''<br />
*# ''Issue 2: Here is the second issue I have.''<br />
<br />
Note: large blocks of italic text are inaccessible to many readers, including people with types of visual impairment, dyslexia, etc. [http://www.intranet.man.ac.uk/accessibility/Disabilities/dyslexia.html], [https://tritonlink.ucsd.edu/portal/site/tritonlink-preview/menuitem.b4448692267a11256ec5e210514b01ca?storyID=20896]. [http://accessites.org/], [http://tlt.psu.edu/suggestions/accessibility/font.html], [http://www.wd4a.co.uk/Guidelines.htm]<br />
<br />
== Related Pages ==<br />
{{hcard-related-pages}}</div>RCaninehttps://microformats.org/wiki/index.php?title=citation-brainstorming&diff=12560citation-brainstorming2006-12-18T17:11:18Z<p>RCanine: /* Working straw schema */</p>
<hr />
<div><h1> Citation Brainstroming </h1><br />
<br />
== See also ==<br />
* [[citation]]<br />
* [[citation-examples]]<br />
* [[citation-formats]]<br />
* [[citation-faq]]<br />
<br />
__TOC__<br />
<br />
== Contributors ==<br />
<br />
* ...<br />
* ... (a bunch of good folks!)<br />
* Tantek Çelik<br />
* Tim White<br />
* Michael McCracken<br />
* Brian Suda<br />
* [[User:AndyMabbett|Andy Mabbett]]<br />
<br />
== Use Cases ==<br />
<br />
To focus the discussion, please add use cases below that will help show what problems the citation microformat will be solving.<br />
<br />
I've included two, focusing on consuming information - I've assumed that use cases for generating microformatted content would just involve the desire to enable your content to be consumed better, but I'm interested to see if there's something I'm missing here -Mike<br />
<br />
=== Acquiring reference information from the web ===<br />
<br />
A user either finds an author's papers page, or is viewing the results of a search and would like to import the information about the displayed papers into their local reference database, for the purposes of cataloging things they've read, adding notes, and using the information to generate later citations, potentially in other forms, such as BibTeX or Docbook, for inclusion in a publication of their own.<br />
<br />
Notes: In this case, it isn't important to the user what format the citation takes as displayed on the page where they find it. What *is* important is that it contains enough information to allow generation of the format they will ultimately re-publish it in. This implies that it may be worthwhile to err a little on the side of verbosity.<br />
<br />
Also, links to downloadable full representations of the cited work are very important - e.g. a link to the PDF of a journal article, or to a music file.<br />
<br />
=== Subscribing to reading lists, periodicals, etc ===<br />
<br />
I would like to be able to leverage my news aggregator with hAtom to subscribe to a remote source for citation information, for example:<br />
<br />
* a reading list for a seminar<br />
* The publication list for a conference (e.g., subscribe to SIGGRAPH and see the updated conference proceedings every year)<br />
* the issues of a journal<br />
* a particular research group or researcher's publications<br />
* Not just research: a popular author's publications (e.g., [http://www.gladwell.com/archive.html Malcolm Gladwell's Archive])<br />
<br />
=== Aggregating reading lists and reviews ===<br />
<br />
A citation microformat-specific aggregator could provide a decentralized version of [http://citeulike.org/ CiteULike]. Libraries, authors, research groups, and publishers could mark up their collections, while other people on weblogs or review sites could add tags and reviews.<br />
<br />
At least, having a well-adopted microformat would make writing tools like CiteULike much better, since it relies in some cases on screen-scraping publisher web-sites.<br />
<br />
=== Cut & Paste from web pages ===<br />
Capturing/copying HTML from web pages for use in other applications (especially when those apps present HTML as output), such as pasting into Word, or a specialized application like [http://www.google.com/notebook Google Notebook], [http://onfolio.com Onfolio] or [http://www.kaboodle.com Kaboodle]. When such captures are made, it makes sense to keep track of the full citation data, including the date it was accessed, which may or may not be the date it was published. <br />
<br />
=== Blogs quoting other resources, including blogs ===<br />
Any blog that cites online content, whether a blog or news article, could use an hCitation to properly link to the cited reference. Such citations could include the access date when the blogger made the citation, because resources on the other side of those links can change without notice. <br />
<br />
Instead, today we have simple formating with a link to the permaURL. The citation data is completely lacking. See [http://doc.weblogs.com Doc Searl's blog] for a style of referencing that could benefit from proper a citation uF.<br />
<br />
<br />
Fascinating... after I added the last two use cases, I realized they focus on potentially marginal cases. The first because it is missing the "output" part of the cut & paste, where the uF would actually be used as part of the paste. The latter because bloggers have a working citation mechanism that is just a link to the URL (hopefully a permaURL). One could argue they wouldn't want a full hCitation. And in fact, until a tool exists that makes it easy, they probably won't. However, a tool that cuts & pastes from anywhere on the web into a blog with a full citation seems like a nice tool. But again, I'm not really paving the cowpaths with these ideas. -Joe Andrieu<br />
<br />
===Finding in Library===<br />
Find a copy of the cited work in a nearby library (as with [http://ocoins.info/ OpenCOinS]). [[User:AndyMabbett|AndyMabbett]] 04:55, 4 Nov 2006 (PST)<br />
<br />
===Buy a copy===<br />
Find the cited work on, for example, Amazon or [http://www.abebooks.com/ ABE]; or subscribe to a journal via its own website. [[User:AndyMabbett|AndyMabbett]] 04:55, 4 Nov 2006 (PST)<br />
<br />
===Find reviews===<br />
Find third-party reviews of the cited work. [[User:AndyMabbett|AndyMabbett]] 04:55, 4 Nov 2006 (PST)<br />
<br />
== Original hBib Discussion ==<br />
<br />
During the WWW2005 Developer's Day [[microformats]] track, Rohit Khare gave a [[presentations|presentation]] where he discussed the microformats [[process]], and then did a quick demonstration wherein a bunch of us got on a shared Subethaedit document, and brainstormed some thoughts on what an "hBib" bibliography citation microformat would look like. Rohit placed the [http://cnlabs.commerce.net/~rohit/hBib%20Discussion.html document on his Commercenet site].<br />
<br />
* http://cnlabs.commerce.net/~rohit/hBib%20Discussion.html<br />
<br />
''An attempt to summarize and inline the linked document follows. -Mike''<br />
<br />
Two major goals were outlined by the group:<br />
<br />
* Avoid re-keying references<br />
* Adapt to new journal styles by changing CSS<br />
<br />
The fundamental problem was discussed in terms of display - the ability to transform XHTML+hBib into the many journal-specific formats. For example, how to display "et.al" when all authors are present in the source, and how to re-order the elements if a style defines a set order of elements that conflicts with the ordering in the source. Using hCard for authors was agreed on, and the beginnings of an example were shown.<br />
<br />
== XHTML Structure ==<br />
With my exprience working X2V and hCa* has taught me what elememts are easy to find and which are not. Since the Citation microformat is very new it is possible to not make a lot of the same errors twice and to make things easier for extracting application to find and imply certain properties.<br />
<br />
* There should be some sort of 'root node' that implies all child elements are for the Citation microformat.<br />
* Since most people will have multiple Citation there should be away to represent each Citation object as a unqiue block independant of another. This is to keep the parse from finding 'author' and applying to all citations. Each citation should be in a container (class="???") that scoped from others.<br />
* Perhaps class="hcite" with <code>&lt;cite&gt;</code> recommended as the root element. E.g. <code>&lt;cite class="hcite"&gt;</code><br />
<br />
== Citation vs. [[media-info]] ==<br />
<br />
What distinguishes a cite from say [[media-info]] (e.g. [[media-info-examples]]) is that a cite is a reference to something explicitly external to the current piece of content or document, whereas [[media-info]] describes information about content embedded or inline in the current document.<br />
<br />
== Semantic Meaning ==<br />
One of the guiding priniciple of Microformats is to use the most semantically rich element to describe each node (Point 2 of Semantic XHTML Design Principles: Use the most accurately precise semantic XHTML building block for each object etc). Since we are dealing with HTML and citations, several elements are candidates to be used to enrich the semantic meaning. [http://www.w3.org/TR/REC-html40/struct/text.html CITE, BLOCKQUOTE, Q, A], (are there more?)<br />
<br />
The [[citation-brainstorming|Citation Brainstorming Page]] has a few development and ideas about how to give another person credit for a link. Some of the semantic ideas behind their choices of tags can be applied to a full bibliographic type reference. ''Does this sentence make sense only historically? -Mike''<br />
<br />
== OCLC's WorldCat for titles == <br />
Question: what about using something like OCLC's [http://www.oclc.org/worldcat/open/isbnissnlinking/default.htm WorldCat] for linking titles? - Tim White<br />
<br />
== This and That ==<br />
After reading through alot of different citation encoding formats, i noticed that each format was being used in onw of two ways. It was either to describe the Current page (THIS.PAGE) or being used to encode references that point to external resources (THAT.PAGE)<br />
<br />
The informatation being encoded was identical for both resources (author, date, name, etc) they just reference different things. For this microformat, i'm not sure if we want to try to solve both problems, or just one? The meta tags in the head element would be the ideal place for information about the THIS.PAGE, but that is not in following with the ideals of microformats where information is human-readable. The THAT.PAGE idea where a list of references is at the end of a document in the form of a bibliography is more inline with the ideals of a microformat where the data is human-readable. That doesn't mean that data about the current document shouldn't be human-readable, so some of the same properties used to reference extermal resources can be used for the current document (THIS.PAGE). To do this a different root item could be used and transforming applications could either extract the citation data about the current page, or information about this page's references.<br />
<br />
This is open for discussion, but either way, i believe that the properties used to describe a page will be the same for both THIS and THAT. [http://suda.co.uk/ brian suda]<br />
<br />
== More on This and That ==<br />
<br />
Citation microformats are being explored as a possibility for citing genealogical information at [http://eatslikeahuman.blogspot.com Dan Lawyer's blog].<br />
<br />
This is a case where frequently the citation would refer to (THIS.PAGE), but would have nested within it a reference to (THAT.PAGE), possibly a few levels deep. For instance, a web page might contain data extracted from a microfilm of a census. The citation would need to include information about the web page, information about the microfilm, and information about the census. Genealogical citations are expected to include the repository (where can this book or microfilm be found. Is this the same as ''venue''?). So, at each level the information should contain the repository of the referenced item. A nesting (recursive) mechanism for citation microformats would be useful in this case. Is this the function of the "container" element in the Straw Format?<br />
<br />
== Date Formatting ==<br />
Since microformats are all about re-use and the accepted way to encode Date-Time has been pretty much settled, then this is a good place to start when dealing with all the different date citation types. <br />
<br />
These are all the different fields from various citation formats that are of temporal nature:<br />
* Date (available | created | dateAccepted | dateCopyrighted | dateSubmitted | issued | modified | valid)<br />
* originInfo/dateIssued<br />
* originInfo/dateCreated<br />
* originInfo/dateCaptured<br />
* originInfo/dateOther<br />
* month<br />
* year<br />
* Copyright Year<br />
* Date - Generic<br />
* Date of Confernce<br />
* Date of Publication<br />
* Date of update/revisou/issuance of database record<br />
* Former Date<br />
* Entry Date for Database Record<br />
* Database Update<br />
* Year of Publication<br />
<br />
There are several common properties across several citation domains and will certainly be in the citation microformat, the unique instances will need further consideration, otherwise there could be no end to posiblities. <br />
<br />
There are also several properties (year, month, Year of publication) that can be extracted from another source. Therefore, if you only encode a more specific property such as; Date of Publication, you can extract the 'year of publication' from that. Since the date-time format we are modeling after is the ISO date-time format, just the Year portion is an acceptable date. So if you ONLY know the year of publication, the you can form a valid 'Date of Publication' as a microformat (which inturn is a valid 'year of publication') - you milage may vary when it comes to importing into citation applications.<br />
<br />
...<br />
<br />
It seems to me that these can be collapsed to maybe one or two different date properties. As far as the specific human readable formatting of the date, that can be chosen per whatever the presentation style guide says, and the [[datetime-design-pattern]] used to simplify the markup. - Tantek<br />
<br />
<br />
'''Important'''<br />
Sometimes we need a date range and not simply a date (e.g. 4-6 May 2006). See ''Conference Citation'' examples later on this page. - Discoleo<br />
<br />
'''Seasons'''<br />
Some journals have seasonal issues (e.g. "Summer 2006 edition") instead of, or as well as, editions labelled by month or other calendar-date. [[User:AndyMabbett|AndyMabbett]] 05:05, 4 Nov 2006 (PST)<br />
<br />
== Tags ==<br />
Some of the citation formats has a place for 'keywords' or 'generic tags', etc. This might be a good place to re-use the [http://microformats.org/wiki/rel-tag RelTag microformat]. The downside would be that they are then forced to be links, which might be the correct way to mark-up these terms.<br />
<br />
<br />
== MARC / MODS / Dublin Core ==<br />
<br />
The MODS ([http://www.loc.gov/standards/marcxml/Sandburg/sandburgmods.xml example]) and Dublin Core ([http://www.loc.gov/standards/marcxml/Sandburg/sandburgdc.xml example]) transformations of MARC21 may contain some useful ideas.<br />
<br />
Here's a first attempt at rewriting the linked examples in XHTML (written in response to a [http://microformats.org/discuss/mail/microformats-discuss/2005-December/002438.html mailing list query about encoding book information with microformats]):<br />
<br />
<pre><nowiki><br />
<div class="book" lang="en"><br />
<h3 class="fn">Arithmetic /</h3><br />
<p>By <span class="creator"><span class="fn">Sandburg, Carl</span>,<br />
<span class="date">1878-1967</span></span>,<br />
and <span class="illustrator">Rand, Ted</span></p><br />
<p>Publisher: <span class="publisher"><span class="fn">Harcourt Brace Jovanovich</span>,<br />
<span class="locality">San Diego</span></span></p><br />
<p>Published: <span class="issued">1993</span></p><br />
<p class="description">A poem about numbers and their characteristics. Features<br />
anamorphic, or distorted, drawings which can be restored to normal by viewing<br />
from a particular angle or by viewing the image's reflection in the provided<br />
Mylar cone.</p><br />
<p class="note">One Mylar sheet included in pocket.</p><br />
<p>Subjects:</p><br />
<ul><br />
<li class="subject">Arithmetic</li><br />
<li class="subject">Children's poetry, American.</li><br />
<li class="subject">Arithmetic</li><br />
<li class="subject">American poetry</li><br />
<li class="subject">Visual perception</li><br />
</ul><br />
</div><br />
</nowiki></pre><br />
<br />
== Basic Citation Stuctures ==<br />
There are basic structures to any citation, this is an overview of some of the types<br />
[http://www.users.muohio.edu/darcusb/misc/citations-spec.html http://www.users.muohio.edu/darcusb/misc/citations-spec.html]<br />
<br />
<br />
== Concerns not addressed by existing formats ==<br />
<br />
There are some aspects '''NOT adequately''' covered by existing formats. I have addressed this issue on the OpenOffice.org wiki page, too. [see http://wiki.services.openoffice.org/wiki/Bibliographic_Database for an extending discussion, the paragraph on ''Reference Types'']<br />
<br />
<br />
These issues pertain mainly to '''Errata''', '''Comments and Authors Reply''' and '''Article Retractions'''.<br />
* a bidirectional link could be necessary to implement these features (original article <=> eratum, reply, retraction letter)<br />
* '''IMPORTANT: Errata'''<br />
** Erata: one or more Corrections might be posted in various issues of the journal<br />
** this is usually cited as: Orininal Article Citation Data (Correction available in ''Journal, Issue Nr, Year, Pages'') (repeat for more than one correction)<br />
** it is possibly never cited alone<br />
** there should be a link to the original article, while the original article should contain a link to this ''Errata''<br />
* '''IMPORTANT: Commentary and Author Reply'''<br />
** similar to Errata, there might be one or more Comments and Author Replys; this should be stored, too<br />
** however, it is usually not included in the original citation<br />
** it might be used however in a citation, but I do not know exaclty how to cite it optimally (original article should be provided as well) <br />
* '''IMPORTANT: Article Retraction'''<br />
** an article may be retracted because of plagiarism or some other flaw<br />
** this should not be used any further in the research<br />
** however, it might be used e.g. for an article on plagiarism or flawed research<br />
** there should be therefore one field storing this information, too, and a link to:<br />
** the published withdrawal letter (which explains why the article was retracted)<br />
<br />
* this issue may need a time-controlled event<br />
* '''IMPORTANT: electronic publishing ahead of print (EPUB)'''<br />
** more and more articles are initially posted online, before the published article gets actually printed<br />
** How should this be used/cited?<br />
** Is this changed, after the print version becomes available?<br />
<br />
<br />
== Outstanding Issues ==<br />
The 3 main points i (Brian) came across so far are:<br />
1) IDENTIFIERS<br />
2) FORMAT TYPES<br />
3) NESTING<br />
<br />
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:<br />
<pre><br />
<nowiki><br />
<div class="uid"><span class="type">ISBN</span>: <span<br />
class="value">123456</span></div><br />
</nowiki><br />
</pre><br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
The two options are:<br />
i) Using class="book"<br />
<pre><br />
<nowiki><br />
<div class="hcite"><br />
<div class="book"><br />
<span class="fn">Book Title</span><br />
<div class="chapter"><br />
<span class="fn">Chapter Title</span><br />
</div><br />
</div><br />
</div><br />
</nowiki><br />
</pre><br />
<br />
This makes things easy to nest and to figure out exactly what is<br />
associated with what, but the downside is that we have enumerated<br />
lists of values for the class properties.<br />
<br />
ii) using the TYPE for book<br />
<pre><br />
<nowiki><br />
<div class="hcite"><br />
<div class="type">book</div><br />
<span class="fn">Book Title</span><br />
<div class="type">chapter</div><br />
<span class="fn">Chapter Title</span><br />
</div><br />
</nowiki><br />
</pre><br />
<br />
now the class="fn" is not nested inside the class="book" or<br />
class="chapter" so there would have to be some other mechanism to<br />
associate the data with the type.<br />
<br />
== Brian's Straw format ==<br />
<br />
=== implied schema (examples) ===<br />
+ publisher<br />
+ language<br />
+ description<br />
+ title<br />
+ creator<br />
+ journal<br />
+ volume<br />
+ issue<br />
+ page <br />
+ edition<br />
+ identifier<br />
+ tags<br />
+ format<br />
+ date published<br />
+ copyright<br />
- audience<br />
<br />
=== implied schema (formats) ===<br />
+ publisher<br />
+ language<br />
+ description<br />
+ title<br />
+ creator<br />
+ volume<br />
+ pages<br />
+ edition<br />
+ issue<br />
+ identifier<br />
+ tags<br />
+ format<br />
+ date published<br />
+ date copyrighted<br />
- subtitle<br />
- image <br />
- excerpt<br />
- index terms<br />
- series title<br />
- publication<br />
- journal<br />
- part (1 of X)<br />
<br />
UNION of the two schemas<br />
+ (PLUS) means common properties<br />
- (MINUS) means unique to the schema<br />
<br />
<br />
=== Working straw schema ===<br />
<br />
Fields<br />
<br />
* title<br />
* creator<br />
* volume<br />
* pages<br />
* edition<br />
* issue<br />
* tags<br />
* format<br />
* date published<br />
* date copyrighted<br />
* publisher<br />
* language<br />
* description<br />
* URI<br />
** encompasses URLs to link to online copies as well as URIs such as urn:isbn: 0521890012<br />
** see discussion from [http://microformats.org/discuss/mail/microformats-discuss/2006-November/007390.html november] and [http://microformats.org/discuss/mail/microformats-discuss/2006-December/007403.html december].<br />
* identifier<br />
<br />
<br />
<br />
=== Examples ===<br />
<br />
Markup examples using the above format:<br />
<br />
==== Book ====<br />
<br />
This is Brian's original example<br />
<br />
<pre><br />
<nowiki><br />
<ul class="bibliography"><br />
<li class="hcite" xml:lang="en-gb"><br />
<br />
<!-- publisher data as hCard--;<br />
<div class="publisher vcard"><br />
<span class="fn org">ABC Publishing Co.</span><br />
<span class="country-name">United Kingdom</span><br />
...<br />
</div><br />
<br />
<!-- author(s) data as hCard --><br />
<div class="creator vcard"><br />
<span class="fn n"><span class="given-name">John <span class="family-name">Doe</span></span><br />
...<br />
</div><br />
<br />
<!-- location data --><br />
<span class="fn">Foobar!</span><br />
<span class="description">World Class Book about foobar</span><br />
<span class="volume">1</span><br />
<span class="issue">1</span><br />
<span class="edition">1</span><br />
<span class=;pages">1-10</span><br />
<span class="format">article</span><br />
<br />
<!-- differed to the UID debate --><br />
<span class="identifier">12345678</span><br />
<br />
<!-- keywords --><br />
<a class="keyword" rel="tag" href="/tags/foo">foo</a><br />
<span class="keyword">bar</span><br />
<br />
<!-- date properties --><br />
Published <abbr class="dtpublished" title="20060101">January 1st 1006</abbr><br />
Copyright <abbr class="copyright" title="20060101">2006</abbr><br />
</li><br />
...<br />
</ul><br />
<br />
<p class="citation">Have you read ;span class="title"><abbr title="book" class="format">Foo Bar</abbr></span>? <br />
It was written by <span class="author vcard"><span class="fn">John Doe</span></span>. <br />
It only came out a <abbr class="dtpublished" title="20060101">few months ago</abbr></p><br />
</nowiki><br />
</pre><br />
<br />
Note: the "format" property above is incorrect. Format would refer more the physical characteristics of an item, rather than its type or genre (e.g. "article", "book", etc.). I'd rather have the main class for the li be "article" in this context, than the fairly meaningless "citation." Of course, one could have both, which would be fine too. -- bruce<br />
<br />
Note: Could we use ROLE from hCard to identify editors, translators, authors, etc?<br />
This was discussed on the mailing list and the idea was dropped [http://microformats.org/discuss/mail/microformats-discuss/2006-September/005694.html]<br />
<br />
'''Comments''' : [[User:Singpolyma|singpolyma]] 08:03, 16 Jun 2006 (PDT) : keywords should be [[rel-tag]], and probably also [[XOXO]] (the same way the citation list is)<br />
<br />
[[User:RCanine|RCanine]] 11:55, 18 Dec 2006 (EST) :<br />
<br />
* Is there a reason not to re-use "published" from hAtom instead of inventing a new, basically equivalent term in "dtpublished"?<br />
* Is the root element "hCite" or "citation". Let me root for "citation" as that semantically describes the content--similar to hCard's root class of "vcard".<br />
* Missing a URL/URI/IRI/UID etc. field example (ISBN for Book).<br />
* Does the "copyright" class conflict with [http://www.whatwg.org/specs/web-apps/current-work/#class WHATWG's definition]?<br />
* WRT Bruce's comment, I'm currently using class="article citation" for my writing, as it has the most flexibility with CSS styles for titles (e.g. Book titles .citation>.fn must be italicized, while article titles must not, their container should).<br />
* Speaking of containers, we need an "in" or "collection" field for journal articles or articles-in-books, or is that covered by "publisher"?<br />
<br />
==== Citing Private Communication ====<br />
<br />
Needs an example.<br />
<br />
==== Citing Legal Cases ====<br />
Needs an example. <br />
see [http://microformats.org/wiki/citation-examples-markup#Wikipedia_Court_Case Wikipedia example] for inspiration.<br />
<br />
==== Citing a Book ====<br />
<br />
needs an example<br />
<br />
==== Citing a journal article ====<br />
<br />
needs an example <br />
<br />
==== Citing a magazine article ====<br />
<br />
needs an example<br />
<br />
==== Citing a Patent ====<br />
<br />
Drawn from this [http://microformats.org/wiki/citation-examples#U.S._Patent example from Wikipedia]:<br />
<br />
<pre><nowiki><br />
<li class="hcite"><a href="http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=4,405,829" class="url" <br />
title="http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=4,405,829"><br />
<span class="format">U.S. Patent</span> <span class="identifier">4,405,829</span></a>:<br />
<span class="description">The <a href="/wiki/RSA" title="RSA">RSA</a> patent, a famous software patent on the ground-breaking <br />
and highly unobvious algorithm for public key encryption, widely used for secure communications <br />
in many industries nowdays</span><br />
</li><br />
</nowiki></pre><br />
<br />
==== Citing a conference publication====<br />
<br />
Based on the [http://microformats.org/wiki/citation-examples#ACM_Digital_Library_Search_Result_Examples conference publication reference example].<br />
<br />
Changed Oct 06 to conform with [http://microformats.org/wiki/citation-brainstorming#Brian.27s_Straw_format Brian's format]. --[[User:Mike|Mike]] 18:09, 12 Oct 2006 (PDT)<br />
(everything but the url class should be in line with that proposal)<br />
<br />
L. Hochstein, J. Carver, F. Shull, S. Asgari, V. Basili, J. K. Hollingsworth, and M. Zelkowitz, “Hpc programmer productivity: A case study of novice hpc programmers,” in Proceedings of ACM/IEEE Supercomputing Conference, 2005.<br />
<br />
<pre><nowiki><br />
<cite class="hcite"><br />
<span class="creator vcard"><span class="fn">Lorin Hochstein</span><span class="org"> University of Maryland, College Park </span><span>,<br />
<span class="creator vcard"><span class="fn"> Jeff Carver </span> <span class="org"> Mississippi State University </span> <span>,<br />
<span class="creator vcard"><span class="fn"> Forrest Shull </span> <span class="org"> Fraunhofer Center Maryland </span> <span>,<br />
<span class="creator vcard"><span class="fn"> Sima Asgari</span> <span class="org"> University of Maryland, College Park </span> <span>,<br />
<span class="creator vcard"><span class="fn"> Victor Basili</span> <span class="org"> Fraunhofer Center Maryland </span> <span>,<br />
<span class="creator vcard"><span class="fn"> Jeffrey K. Hollingsworth</span> <span class="org"> University of Maryland, College Park </span> <span>, and <br />
<span class="creator vcard"><span class="fn"> Marv Zelkowitz</span> <span class="org"> University of Maryland, College Park </span> <span>,<br />
<a class="fn url" href="http://dx.doi.org/10.1109/SC.2005.53">HPC Programmer Productivity: A Case Study of Novice HPC Programmers</a>. <br />
(<span class="format">conference publication</span>)<br />
<cite class="container hcite"><br />
<a class="fn url" href="...">Proceedings of ACM/IEEE Supercomputing Conference</a><br />
<abbr class="dtpublished" title="20051126T0000-0800">2005</abbr><br />
</cite><br />
page <span class="pages">35</span><br />
<div class="publisher vcard"><br />
<span class=" fn">IEEE Computer Society<br />
</span><br />
<div class="adr"><br />
<span class="locality">Washington</span>,<br />
<span class="region">DC</span><br />
</div><br />
</div><br />
<a class="url instantiation" href="http://portal.acm.org/ft_gateway.cfm?id=1105800&type=pdf&coll=portal&dl=ACM&CFID=68330711&CFTOKEN=39187329">PDF of full text from ACM</a><br />
<br />
DOI: <a class="url uid" href="http://dx.doi.org/10.1109/SC.2005.53">10.1109/SC.2005.53</a><br />
Tags: <br />
<a class="keyword" rel="tag" href="results.cfm?query=genterm%3A%22Design%22 ..."><br />
Design</a>,<br />
<a class="keyword" rel="tag" href="results.cfm?query=genterm%3A%22Experimentation%22 ...."><br />
Experimentation</a>,<br />
<a class="keyword" rel="tag" href="results.cfm?query=genterm%3A%22Measurement%22..."><br />
Measurement</a>,<br />
<a class="keyword" rel="tag" href="results.cfm?query=genterm%3A%22Performance%22 ..."><br />
Performance</a><br />
<br />
<blockquote class="description">In developing High-Performance Computing (HPC) software, time to solution is an important metric. This metric is comprised of two main components: the human effort required developing the software, plus the amount of machine time required to execute it. To date, little empirical work has been done to study the first component: the human effort required and the effects of approaches and practices that may be used to reduce it. In this paper, we describe a series of studies that address this problem. We instrumented the development process used in multiple HPC classroom environments. We analyzed data within and across such studies, varying factors such as the parallel programming model used and the application being developed, to understand their impact on the development process.<br />
</blockquote><br />
</cite><br />
</nowiki></pre><br />
<br />
<br />
'''Note''' (From [[Discoleo]], Sept. 06)<br />
* sometimes, the citation must include '''Town/Country''' and '''Precise Date/Date Range''', e.g.<br />
** ''Gillespie SH, Dickens A.'' Variation in mutation rate of quinolone resistance in Streptococcus pneumoniae [abstract P06-17A]. In: Abstracts of the 3rd International Symposium on Pneumococci and Pneumococcal Disease (Anchorage, 5-9 May 2002).Washington, DC: American Society of Microbiology, 2002.<br />
** ''Bassetti, M.; Righi, E.; Rebesco, B.; Molinari, MP.; Costa, A.; Fasce, R.; Cruciani, M.; Bassetti, D.; Bobbio Pallavicini, F.'' 44th Annual Interscience Conference on Antimicrobial Agents and Chemotherapy (ICAAC). Washington, DC; 2004. Epidemiological trends in nosocomial candidemia in ICU: A five-year Italian perspective.<br />
** ''Peacock JE, Wade JC, Lazarus HM, et al.'' Ciprofloxacin/piperacillin vs. tobramycin/piperacillin as empiric therapy for fever in neutropenic cancer patients, a randomized, double-blind trial [abstract 373]. In: Program and abstracts of the 37th Interscience Conference on Antimicrob Agents and Chemotherapy (Toronto). Washington, DC: American Society for Microbiology, 1997.<br />
<br />
==== Citing an external website ====<br />
<br />
This is based on a formal citation of a website in the references section of a research paper, but could also be used for in-line links that had added information. Here's the original:<br />
<br />
[25] David Stern, "eprint Moderator Model", http://www.library.yale.edu/scilib/modmodexplain.html (version dated Jan 25, 1999)<br />
<br />
<pre><nowiki><br />
<cite class="citation"><br />
<a class="fn url" href="http://www.library.yale.edu/scilib/modmodexplain.html">eprint Moderator Model</a><br />
<span class="author vcard"><br />
<a href="http://pantheon.yale.edu/~dstern/dsbio.html" class="url fn">David Stern</a><br />
</span> <br />
<abbr class="dtpublished" title="19990125T0000-0500"><br />
Jan 25, 1999<br />
</abbr><br />
</cite><br />
</nowiki></pre><br />
<br />
== Old straw format discussion ==<br />
<br />
Saved here so that I'm not just deleting people's comments.<br />
<br />
<br />
=== Mike straw format suggestion (Deprecated) ===<br />
<br />
In the interests of starting debate and having something concrete to fix, I suggest the following structure for a format. It is probably very incomplete and I claim no microformat expertise. I'm just trying to follow existing patterns. Comments and ridicule are both solicited. -Mike<br />
<br />
'''NOTE:''' This format is here for historical reference. Because it was not based on existing examples, I've deprecated it and contributed examples to Brian's format. If you feel that any missing elements in here should be in the final format, find examples for them and contribute to Brian's schema. Thanks! --[[User:Mike|Mike]] 18:22, 12 Oct 2006 (PDT)<br />
<br />
==== In General ====<br />
<br />
The ''citation'' format is based on a set of fields common to many bibliographic data formats, which are often implied by standard citation display styles but not explicitly marked up in practice on the web.<br />
<br />
==== Schema ====<br />
<br />
The citation schema consists of the following:<br />
<br />
* cite <br />
** title: required, text (class = fn)<br />
** subtitle: optional, text<br />
** authors: optional, use hCard<br />
** publication date: optional<br />
** link(s) to instantiations, optional, url or use rel-enclosure? (class=url)<br />
** UID, optional (for ISBN, DOI - use existing uid class) | permalink<br />
** series (aka volume/issuenum) , optional (''not as sure how to handle these - suggestions?'')<br />
** pages: startpage & endpage, optional, text<br />
** venue, optional (hCard)<br />
** publisher, optional (hCard)<br />
** container: optional (nested hCite)<br />
** abstract, optional (blockquote + class="abstract" ?)<br />
** notes, optional (blockquote + class="notes" ?)<br />
** keywords, optional (rel-tag)<br />
** image, optional (for inclusion inline, unlike the url)<br />
** copyright, optional (rel-license)<br />
** ''what else am I missing?''<br />
*** language, optional<br />
<br />
''Looks good, but I question the use of hCard for names. Due to ambiguity issues, requring hCard would lead to extra markup in order to apply just a name, hence [http://microformats.org/discuss/mail/microformats-discuss/2006-March/003487.html the need for a root element]. We should extract the N optimization of hCard like we did with adr, in order to ease this problem.'' --[[User:RCanine|Ryan Cannon]]<br />
<br />
Perhaps a Retrieved Date or Access Date would be appropriate for citing online resources. For example at http://www.crlt.umich.edu/publinks/facment_biblio.html <br />
you see citations like this<nowiki>:</nowiki><br />
<blockquote><br />
Chief Academic Officers of the Big 12 Universities (2000). Big 12 Faculty Fellowship Program. Retrieved December 20, 2000 from the World Wide Web: http://www.k-state.edu/provost/academic/big12/big12guide.htm.<br />
</blockquote><br />
--[[User:JoeAndrieu|Joe Andrieu]]<br />
<br />
<br />
==== Discussion about citing legal cases ====<br />
<br />
Here's some info I found about citing law:<br />
<br />
I'm not a lawyer, so I'm relying on the published [http://www.legalbluebook.com "blue book" standard], at least the only part of it I can get without paying $25. I'd be happy to hear improvements from experts in the field - how do lawyers mark up references to case law in HTML now?<br />
<br />
From groklaw.net and eff.org, I find mostly just links to PDFs with the name of the case as the link text. Or just this, from EFF:<br />
<pre><nowiki><br />
<h1>The Betamax Case</h1><br />
<h2>Sony Corp. of America v. Universal City Studios, 464 U.S. 417 (1984)</h2><br />
</nowiki></pre><br />
<br />
From an example at the sample bluepages: http://www.legalbluebook.com/pdfs/bluepages.pdf<br />
5 basic components:<br />
*1 name of the case (citation title)<br />
*2 published source in which case may be found (citation containing publication?)<br />
*3 a parenthetical indicating the court and year of decision (citation venue?)<br />
*4 other parenthetical information, if any (citation notes?)<br />
*5 subsequent history of the case, if any (citation notes?)<br />
<br />
Here's two examples from the bluebook. Note that there are very strict rules about abbreviations in that source!<br />
<br />
Holland v. Donnelly, 216 F. Supp. 2d 227, 230 (S.D.N.Y. 2002), aff'd, 324 F.3d 99 (2d Cir. 2003).<br />
<br />
Green v. Georgia, 442 U.S. 95, 97 (1979) (per curiam) (holding that exclusion of relevant evidence at sentencing hearing constitutes denial of due process).<br />
<br />
<br />
<br />
== discussions ==<br />
* [[citation-irc-notes-2006-04-09]]</div>RCaninehttps://microformats.org/wiki/index.php?title=citation-brainstorming&diff=11601citation-brainstorming2006-12-18T17:10:56Z<p>RCanine: /* Examples */</p>
<hr />
<div><h1> Citation Brainstroming </h1><br />
<br />
== See also ==<br />
* [[citation]]<br />
* [[citation-examples]]<br />
* [[citation-formats]]<br />
* [[citation-faq]]<br />
<br />
__TOC__<br />
<br />
== Contributors ==<br />
<br />
* ...<br />
* ... (a bunch of good folks!)<br />
* Tantek Çelik<br />
* Tim White<br />
* Michael McCracken<br />
* Brian Suda<br />
* [[User:AndyMabbett|Andy Mabbett]]<br />
<br />
== Use Cases ==<br />
<br />
To focus the discussion, please add use cases below that will help show what problems the citation microformat will be solving.<br />
<br />
I've included two, focusing on consuming information - I've assumed that use cases for generating microformatted content would just involve the desire to enable your content to be consumed better, but I'm interested to see if there's something I'm missing here -Mike<br />
<br />
=== Acquiring reference information from the web ===<br />
<br />
A user either finds an author's papers page, or is viewing the results of a search and would like to import the information about the displayed papers into their local reference database, for the purposes of cataloging things they've read, adding notes, and using the information to generate later citations, potentially in other forms, such as BibTeX or Docbook, for inclusion in a publication of their own.<br />
<br />
Notes: In this case, it isn't important to the user what format the citation takes as displayed on the page where they find it. What *is* important is that it contains enough information to allow generation of the format they will ultimately re-publish it in. This implies that it may be worthwhile to err a little on the side of verbosity.<br />
<br />
Also, links to downloadable full representations of the cited work are very important - e.g. a link to the PDF of a journal article, or to a music file.<br />
<br />
=== Subscribing to reading lists, periodicals, etc ===<br />
<br />
I would like to be able to leverage my news aggregator with hAtom to subscribe to a remote source for citation information, for example:<br />
<br />
* a reading list for a seminar<br />
* The publication list for a conference (e.g., subscribe to SIGGRAPH and see the updated conference proceedings every year)<br />
* the issues of a journal<br />
* a particular research group or researcher's publications<br />
* Not just research: a popular author's publications (e.g., [http://www.gladwell.com/archive.html Malcolm Gladwell's Archive])<br />
<br />
=== Aggregating reading lists and reviews ===<br />
<br />
A citation microformat-specific aggregator could provide a decentralized version of [http://citeulike.org/ CiteULike]. Libraries, authors, research groups, and publishers could mark up their collections, while other people on weblogs or review sites could add tags and reviews.<br />
<br />
At least, having a well-adopted microformat would make writing tools like CiteULike much better, since it relies in some cases on screen-scraping publisher web-sites.<br />
<br />
=== Cut & Paste from web pages ===<br />
Capturing/copying HTML from web pages for use in other applications (especially when those apps present HTML as output), such as pasting into Word, or a specialized application like [http://www.google.com/notebook Google Notebook], [http://onfolio.com Onfolio] or [http://www.kaboodle.com Kaboodle]. When such captures are made, it makes sense to keep track of the full citation data, including the date it was accessed, which may or may not be the date it was published. <br />
<br />
=== Blogs quoting other resources, including blogs ===<br />
Any blog that cites online content, whether a blog or news article, could use an hCitation to properly link to the cited reference. Such citations could include the access date when the blogger made the citation, because resources on the other side of those links can change without notice. <br />
<br />
Instead, today we have simple formating with a link to the permaURL. The citation data is completely lacking. See [http://doc.weblogs.com Doc Searl's blog] for a style of referencing that could benefit from proper a citation uF.<br />
<br />
<br />
Fascinating... after I added the last two use cases, I realized they focus on potentially marginal cases. The first because it is missing the "output" part of the cut & paste, where the uF would actually be used as part of the paste. The latter because bloggers have a working citation mechanism that is just a link to the URL (hopefully a permaURL). One could argue they wouldn't want a full hCitation. And in fact, until a tool exists that makes it easy, they probably won't. However, a tool that cuts & pastes from anywhere on the web into a blog with a full citation seems like a nice tool. But again, I'm not really paving the cowpaths with these ideas. -Joe Andrieu<br />
<br />
===Finding in Library===<br />
Find a copy of the cited work in a nearby library (as with [http://ocoins.info/ OpenCOinS]). [[User:AndyMabbett|AndyMabbett]] 04:55, 4 Nov 2006 (PST)<br />
<br />
===Buy a copy===<br />
Find the cited work on, for example, Amazon or [http://www.abebooks.com/ ABE]; or subscribe to a journal via its own website. [[User:AndyMabbett|AndyMabbett]] 04:55, 4 Nov 2006 (PST)<br />
<br />
===Find reviews===<br />
Find third-party reviews of the cited work. [[User:AndyMabbett|AndyMabbett]] 04:55, 4 Nov 2006 (PST)<br />
<br />
== Original hBib Discussion ==<br />
<br />
During the WWW2005 Developer's Day [[microformats]] track, Rohit Khare gave a [[presentations|presentation]] where he discussed the microformats [[process]], and then did a quick demonstration wherein a bunch of us got on a shared Subethaedit document, and brainstormed some thoughts on what an "hBib" bibliography citation microformat would look like. Rohit placed the [http://cnlabs.commerce.net/~rohit/hBib%20Discussion.html document on his Commercenet site].<br />
<br />
* http://cnlabs.commerce.net/~rohit/hBib%20Discussion.html<br />
<br />
''An attempt to summarize and inline the linked document follows. -Mike''<br />
<br />
Two major goals were outlined by the group:<br />
<br />
* Avoid re-keying references<br />
* Adapt to new journal styles by changing CSS<br />
<br />
The fundamental problem was discussed in terms of display - the ability to transform XHTML+hBib into the many journal-specific formats. For example, how to display "et.al" when all authors are present in the source, and how to re-order the elements if a style defines a set order of elements that conflicts with the ordering in the source. Using hCard for authors was agreed on, and the beginnings of an example were shown.<br />
<br />
== XHTML Structure ==<br />
With my exprience working X2V and hCa* has taught me what elememts are easy to find and which are not. Since the Citation microformat is very new it is possible to not make a lot of the same errors twice and to make things easier for extracting application to find and imply certain properties.<br />
<br />
* There should be some sort of 'root node' that implies all child elements are for the Citation microformat.<br />
* Since most people will have multiple Citation there should be away to represent each Citation object as a unqiue block independant of another. This is to keep the parse from finding 'author' and applying to all citations. Each citation should be in a container (class="???") that scoped from others.<br />
* Perhaps class="hcite" with <code>&lt;cite&gt;</code> recommended as the root element. E.g. <code>&lt;cite class="hcite"&gt;</code><br />
<br />
== Citation vs. [[media-info]] ==<br />
<br />
What distinguishes a cite from say [[media-info]] (e.g. [[media-info-examples]]) is that a cite is a reference to something explicitly external to the current piece of content or document, whereas [[media-info]] describes information about content embedded or inline in the current document.<br />
<br />
== Semantic Meaning ==<br />
One of the guiding priniciple of Microformats is to use the most semantically rich element to describe each node (Point 2 of Semantic XHTML Design Principles: Use the most accurately precise semantic XHTML building block for each object etc). Since we are dealing with HTML and citations, several elements are candidates to be used to enrich the semantic meaning. [http://www.w3.org/TR/REC-html40/struct/text.html CITE, BLOCKQUOTE, Q, A], (are there more?)<br />
<br />
The [[citation-brainstorming|Citation Brainstorming Page]] has a few development and ideas about how to give another person credit for a link. Some of the semantic ideas behind their choices of tags can be applied to a full bibliographic type reference. ''Does this sentence make sense only historically? -Mike''<br />
<br />
== OCLC's WorldCat for titles == <br />
Question: what about using something like OCLC's [http://www.oclc.org/worldcat/open/isbnissnlinking/default.htm WorldCat] for linking titles? - Tim White<br />
<br />
== This and That ==<br />
After reading through alot of different citation encoding formats, i noticed that each format was being used in onw of two ways. It was either to describe the Current page (THIS.PAGE) or being used to encode references that point to external resources (THAT.PAGE)<br />
<br />
The informatation being encoded was identical for both resources (author, date, name, etc) they just reference different things. For this microformat, i'm not sure if we want to try to solve both problems, or just one? The meta tags in the head element would be the ideal place for information about the THIS.PAGE, but that is not in following with the ideals of microformats where information is human-readable. The THAT.PAGE idea where a list of references is at the end of a document in the form of a bibliography is more inline with the ideals of a microformat where the data is human-readable. That doesn't mean that data about the current document shouldn't be human-readable, so some of the same properties used to reference extermal resources can be used for the current document (THIS.PAGE). To do this a different root item could be used and transforming applications could either extract the citation data about the current page, or information about this page's references.<br />
<br />
This is open for discussion, but either way, i believe that the properties used to describe a page will be the same for both THIS and THAT. [http://suda.co.uk/ brian suda]<br />
<br />
== More on This and That ==<br />
<br />
Citation microformats are being explored as a possibility for citing genealogical information at [http://eatslikeahuman.blogspot.com Dan Lawyer's blog].<br />
<br />
This is a case where frequently the citation would refer to (THIS.PAGE), but would have nested within it a reference to (THAT.PAGE), possibly a few levels deep. For instance, a web page might contain data extracted from a microfilm of a census. The citation would need to include information about the web page, information about the microfilm, and information about the census. Genealogical citations are expected to include the repository (where can this book or microfilm be found. Is this the same as ''venue''?). So, at each level the information should contain the repository of the referenced item. A nesting (recursive) mechanism for citation microformats would be useful in this case. Is this the function of the "container" element in the Straw Format?<br />
<br />
== Date Formatting ==<br />
Since microformats are all about re-use and the accepted way to encode Date-Time has been pretty much settled, then this is a good place to start when dealing with all the different date citation types. <br />
<br />
These are all the different fields from various citation formats that are of temporal nature:<br />
* Date (available | created | dateAccepted | dateCopyrighted | dateSubmitted | issued | modified | valid)<br />
* originInfo/dateIssued<br />
* originInfo/dateCreated<br />
* originInfo/dateCaptured<br />
* originInfo/dateOther<br />
* month<br />
* year<br />
* Copyright Year<br />
* Date - Generic<br />
* Date of Confernce<br />
* Date of Publication<br />
* Date of update/revisou/issuance of database record<br />
* Former Date<br />
* Entry Date for Database Record<br />
* Database Update<br />
* Year of Publication<br />
<br />
There are several common properties across several citation domains and will certainly be in the citation microformat, the unique instances will need further consideration, otherwise there could be no end to posiblities. <br />
<br />
There are also several properties (year, month, Year of publication) that can be extracted from another source. Therefore, if you only encode a more specific property such as; Date of Publication, you can extract the 'year of publication' from that. Since the date-time format we are modeling after is the ISO date-time format, just the Year portion is an acceptable date. So if you ONLY know the year of publication, the you can form a valid 'Date of Publication' as a microformat (which inturn is a valid 'year of publication') - you milage may vary when it comes to importing into citation applications.<br />
<br />
...<br />
<br />
It seems to me that these can be collapsed to maybe one or two different date properties. As far as the specific human readable formatting of the date, that can be chosen per whatever the presentation style guide says, and the [[datetime-design-pattern]] used to simplify the markup. - Tantek<br />
<br />
<br />
'''Important'''<br />
Sometimes we need a date range and not simply a date (e.g. 4-6 May 2006). See ''Conference Citation'' examples later on this page. - Discoleo<br />
<br />
'''Seasons'''<br />
Some journals have seasonal issues (e.g. "Summer 2006 edition") instead of, or as well as, editions labelled by month or other calendar-date. [[User:AndyMabbett|AndyMabbett]] 05:05, 4 Nov 2006 (PST)<br />
<br />
== Tags ==<br />
Some of the citation formats has a place for 'keywords' or 'generic tags', etc. This might be a good place to re-use the [http://microformats.org/wiki/rel-tag RelTag microformat]. The downside would be that they are then forced to be links, which might be the correct way to mark-up these terms.<br />
<br />
<br />
== MARC / MODS / Dublin Core ==<br />
<br />
The MODS ([http://www.loc.gov/standards/marcxml/Sandburg/sandburgmods.xml example]) and Dublin Core ([http://www.loc.gov/standards/marcxml/Sandburg/sandburgdc.xml example]) transformations of MARC21 may contain some useful ideas.<br />
<br />
Here's a first attempt at rewriting the linked examples in XHTML (written in response to a [http://microformats.org/discuss/mail/microformats-discuss/2005-December/002438.html mailing list query about encoding book information with microformats]):<br />
<br />
<pre><nowiki><br />
<div class="book" lang="en"><br />
<h3 class="fn">Arithmetic /</h3><br />
<p>By <span class="creator"><span class="fn">Sandburg, Carl</span>,<br />
<span class="date">1878-1967</span></span>,<br />
and <span class="illustrator">Rand, Ted</span></p><br />
<p>Publisher: <span class="publisher"><span class="fn">Harcourt Brace Jovanovich</span>,<br />
<span class="locality">San Diego</span></span></p><br />
<p>Published: <span class="issued">1993</span></p><br />
<p class="description">A poem about numbers and their characteristics. Features<br />
anamorphic, or distorted, drawings which can be restored to normal by viewing<br />
from a particular angle or by viewing the image's reflection in the provided<br />
Mylar cone.</p><br />
<p class="note">One Mylar sheet included in pocket.</p><br />
<p>Subjects:</p><br />
<ul><br />
<li class="subject">Arithmetic</li><br />
<li class="subject">Children's poetry, American.</li><br />
<li class="subject">Arithmetic</li><br />
<li class="subject">American poetry</li><br />
<li class="subject">Visual perception</li><br />
</ul><br />
</div><br />
</nowiki></pre><br />
<br />
== Basic Citation Stuctures ==<br />
There are basic structures to any citation, this is an overview of some of the types<br />
[http://www.users.muohio.edu/darcusb/misc/citations-spec.html http://www.users.muohio.edu/darcusb/misc/citations-spec.html]<br />
<br />
<br />
== Concerns not addressed by existing formats ==<br />
<br />
There are some aspects '''NOT adequately''' covered by existing formats. I have addressed this issue on the OpenOffice.org wiki page, too. [see http://wiki.services.openoffice.org/wiki/Bibliographic_Database for an extending discussion, the paragraph on ''Reference Types'']<br />
<br />
<br />
These issues pertain mainly to '''Errata''', '''Comments and Authors Reply''' and '''Article Retractions'''.<br />
* a bidirectional link could be necessary to implement these features (original article <=> eratum, reply, retraction letter)<br />
* '''IMPORTANT: Errata'''<br />
** Erata: one or more Corrections might be posted in various issues of the journal<br />
** this is usually cited as: Orininal Article Citation Data (Correction available in ''Journal, Issue Nr, Year, Pages'') (repeat for more than one correction)<br />
** it is possibly never cited alone<br />
** there should be a link to the original article, while the original article should contain a link to this ''Errata''<br />
* '''IMPORTANT: Commentary and Author Reply'''<br />
** similar to Errata, there might be one or more Comments and Author Replys; this should be stored, too<br />
** however, it is usually not included in the original citation<br />
** it might be used however in a citation, but I do not know exaclty how to cite it optimally (original article should be provided as well) <br />
* '''IMPORTANT: Article Retraction'''<br />
** an article may be retracted because of plagiarism or some other flaw<br />
** this should not be used any further in the research<br />
** however, it might be used e.g. for an article on plagiarism or flawed research<br />
** there should be therefore one field storing this information, too, and a link to:<br />
** the published withdrawal letter (which explains why the article was retracted)<br />
<br />
* this issue may need a time-controlled event<br />
* '''IMPORTANT: electronic publishing ahead of print (EPUB)'''<br />
** more and more articles are initially posted online, before the published article gets actually printed<br />
** How should this be used/cited?<br />
** Is this changed, after the print version becomes available?<br />
<br />
<br />
== Outstanding Issues ==<br />
The 3 main points i (Brian) came across so far are:<br />
1) IDENTIFIERS<br />
2) FORMAT TYPES<br />
3) NESTING<br />
<br />
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:<br />
<pre><br />
<nowiki><br />
<div class="uid"><span class="type">ISBN</span>: <span<br />
class="value">123456</span></div><br />
</nowiki><br />
</pre><br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
The two options are:<br />
i) Using class="book"<br />
<pre><br />
<nowiki><br />
<div class="hcite"><br />
<div class="book"><br />
<span class="fn">Book Title</span><br />
<div class="chapter"><br />
<span class="fn">Chapter Title</span><br />
</div><br />
</div><br />
</div><br />
</nowiki><br />
</pre><br />
<br />
This makes things easy to nest and to figure out exactly what is<br />
associated with what, but the downside is that we have enumerated<br />
lists of values for the class properties.<br />
<br />
ii) using the TYPE for book<br />
<pre><br />
<nowiki><br />
<div class="hcite"><br />
<div class="type">book</div><br />
<span class="fn">Book Title</span><br />
<div class="type">chapter</div><br />
<span class="fn">Chapter Title</span><br />
</div><br />
</nowiki><br />
</pre><br />
<br />
now the class="fn" is not nested inside the class="book" or<br />
class="chapter" so there would have to be some other mechanism to<br />
associate the data with the type.<br />
<br />
== Brian's Straw format ==<br />
<br />
=== implied schema (examples) ===<br />
+ publisher<br />
+ language<br />
+ description<br />
+ title<br />
+ creator<br />
+ journal<br />
+ volume<br />
+ issue<br />
+ page <br />
+ edition<br />
+ identifier<br />
+ tags<br />
+ format<br />
+ date published<br />
+ copyright<br />
- audience<br />
<br />
=== implied schema (formats) ===<br />
+ publisher<br />
+ language<br />
+ description<br />
+ title<br />
+ creator<br />
+ volume<br />
+ pages<br />
+ edition<br />
+ issue<br />
+ identifier<br />
+ tags<br />
+ format<br />
+ date published<br />
+ date copyrighted<br />
- subtitle<br />
- image <br />
- excerpt<br />
- index terms<br />
- series title<br />
- publication<br />
- journal<br />
- part (1 of X)<br />
<br />
UNION of the two schemas<br />
+ (PLUS) means common properties<br />
- (MINUS) means unique to the schema<br />
<br />
<br />
=== Working straw schema ===<br />
<br />
Fields<br />
<br />
* title<br />
* creator<br />
* volume<br />
* pages<br />
* edition<br />
* issue<br />
* tags<br />
* format<br />
* date published<br />
* date copyrighted<br />
* publisher<br />
* language<br />
* description<br />
* URI<br />
** encompasses URLs to link to online copies as well as URIs such as urn:isbn: 0521890012<br />
** see discussion from [http://microformats.org/discuss/mail/microformats-discuss/2006-November/007390.html november] and [http://microformats.org/discuss/mail/microformats-discuss/2006-December/007403.html december].<br />
* identifier<br />
<br />
<br />
<br />
&t=== Examples ===<br />
<br />
Markup examples using the above format:<br />
<br />
==== Book ====<br />
<br />
This is Brian's original example<br />
<br />
<pre><br />
<nowiki><br />
<ul class="bibliography"><br />
<li class="hcite" xml:lang="en-gb"><br />
<br />
<!-- publisher data as hCard--;<br />
<div class="publisher vcard"><br />
<span class="fn org">ABC Publishing Co.</span><br />
<span class="country-name">United Kingdom</span><br />
...<br />
</div><br />
<br />
<!-- author(s) data as hCard --><br />
<div class="creator vcard"><br />
<span class="fn n"><span class="given-name">John <span class="family-name">Doe</span></span><br />
...<br />
</div><br />
<br />
<!-- location data --><br />
<span class="fn">Foobar!</span><br />
<span class="description">World Class Book about foobar</span><br />
<span class="volume">1</span><br />
<span class="issue">1</span><br />
<span class="edition">1</span><br />
<span class=;pages">1-10</span><br />
<span class="format">article</span><br />
<br />
<!-- differed to the UID debate --><br />
<span class="identifier">12345678</span><br />
<br />
<!-- keywords --><br />
<a class="keyword" rel="tag" href="/tags/foo">foo</a><br />
<span class="keyword">bar</span><br />
<br />
<!-- date properties --><br />
Published <abbr class="dtpublished" title="20060101">January 1st 1006</abbr><br />
Copyright <abbr class="copyright" title="20060101">2006</abbr><br />
</li><br />
...<br />
</ul><br />
<br />
<p class="citation">Have you read ;span class="title"><abbr title="book" class="format">Foo Bar</abbr></span>? <br />
It was written by <span class="author vcard"><span class="fn">John Doe</span></span>. <br />
It only came out a <abbr class="dtpublished" title="20060101">few months ago</abbr></p><br />
</nowiki><br />
</pre><br />
<br />
Note: the "format" property above is incorrect. Format would refer more the physical characteristics of an item, rather than its type or genre (e.g. "article", "book", etc.). I'd rather have the main class for the li be "article" in this context, than the fairly meaningless "citation." Of course, one could have both, which would be fine too. -- bruce<br />
<br />
Note: Could we use ROLE from hCard to identify editors, translators, authors, etc?<br />
This was discussed on the mailing list and the idea was dropped [http://microformats.org/discuss/mail/microformats-discuss/2006-September/005694.html]<br />
<br />
'''Comments''' : [[User:Singpolyma|singpolyma]] 08:03, 16 Jun 2006 (PDT) : keywords should be [[rel-tag]], and probably also [[XOXO]] (the same way the citation list is)<br />
<br />
[[User:RCanine|RCanine]] 11:55, 18 Dec 2006 (EST) :<br />
<br />
* Is there a reason not to re-use "published" from hAtom instead of inventing a new, basically equivalent term in "dtpublished"?<br />
* Is the root element "hCite" or "citation". Let me root for "citation" as that semantically describes the content--similar to hCard's root class of "vcard".<br />
* Missing a URL/URI/IRI/UID etc. field example (ISBN for Book).<br />
* Does the "copyright" class conflict with [http://www.whatwg.org/specs/web-apps/current-work/#class WHATWG's definition]?<br />
* WRT Bruce's comment, I'm currently using class="article citation" for my writing, as it has the most flexibility with CSS styles for titles (e.g. Book titles .citation>.fn must be italicized, while article titles must not, their container should).<br />
* Speaking of containers, we need an "in" or "collection" field for journal articles or articles-in-books, or is that covered by "publisher"?<br />
<br />
==== Citing Private Communication ====<br />
<br />
Needs an example.<br />
<br />
==== Citing Legal Cases ====<br />
Needs an example. <br />
see [http://microformats.org/wiki/citation-examples-markup#Wikipedia_Court_Case Wikipedia example] for inspiration.<br />
<br />
==== Citing a Book ====<br />
<br />
needs an example<br />
<br />
==== Citing a journal article ====<br />
<br />
needs an example <br />
<br />
==== Citing a magazine article ====<br />
<br />
needs an example<br />
<br />
==== Citing a Patent ====<br />
<br />
Drawn from this [http://microformats.org/wiki/citation-examples#U.S._Patent example from Wikipedia]:<br />
<br />
<pre><nowiki><br />
<li class="hcite"><a href="http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=4,405,829" class="url" <br />
title="http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=4,405,829"><br />
<span class="format">U.S. Patent</span> <span class="identifier">4,405,829</span></a>:<br />
<span class="description">The <a href="/wiki/RSA" title="RSA">RSA</a> patent, a famous software patent on the ground-breaking <br />
and highly unobvious algorithm for public key encryption, widely used for secure communications <br />
in many industries nowdays</span><br />
</li><br />
</nowiki></pre><br />
<br />
==== Citing a conference publication====<br />
<br />
Based on the [http://microformats.org/wiki/citation-examples#ACM_Digital_Library_Search_Result_Examples conference publication reference example].<br />
<br />
Changed Oct 06 to conform with [http://microformats.org/wiki/citation-brainstorming#Brian.27s_Straw_format Brian's format]. --[[User:Mike|Mike]] 18:09, 12 Oct 2006 (PDT)<br />
(everything but the url class should be in line with that proposal)<br />
<br />
L. Hochstein, J. Carver, F. Shull, S. Asgari, V. Basili, J. K. Hollingsworth, and M. Zelkowitz, “Hpc programmer productivity: A case study of novice hpc programmers,” in Proceedings of ACM/IEEE Supercomputing Conference, 2005.<br />
<br />
<pre><nowiki><br />
<cite class="hcite"><br />
<span class="creator vcard"><span class="fn">Lorin Hochstein</span><span class="org"> University of Maryland, College Park </span><span>,<br />
<span class="creator vcard"><span class="fn"> Jeff Carver </span> <span class="org"> Mississippi State University </span> <span>,<br />
<span class="creator vcard"><span class="fn"> Forrest Shull </span> <span class="org"> Fraunhofer Center Maryland </span> <span>,<br />
<span class="creator vcard"><span class="fn"> Sima Asgari</span> <span class="org"> University of Maryland, College Park </span> <span>,<br />
<span class="creator vcard"><span class="fn"> Victor Basili</span> <span class="org"> Fraunhofer Center Maryland </span> <span>,<br />
<span class="creator vcard"><span class="fn"> Jeffrey K. Hollingsworth</span> <span class="org"> University of Maryland, College Park </span> <span>, and <br />
<span class="creator vcard"><span class="fn"> Marv Zelkowitz</span> <span class="org"> University of Maryland, College Park </span> <span>,<br />
<a class="fn url" href="http://dx.doi.org/10.1109/SC.2005.53">HPC Programmer Productivity: A Case Study of Novice HPC Programmers</a>. <br />
(<span class="format">conference publication</span>)<br />
<cite class="container hcite"><br />
<a class="fn url" href="...">Proceedings of ACM/IEEE Supercomputing Conference</a><br />
<abbr class="dtpublished" title="20051126T0000-0800">2005</abbr><br />
</cite><br />
page <span class="pages">35</span><br />
<div class="publisher vcard"><br />
<span class=" fn">IEEE Computer Society<br />
</span><br />
<div class="adr"><br />
<span class="locality">Washington</span>,<br />
<span class="region">DC</span><br />
</div><br />
</div><br />
<a class="url instantiation" href="http://portal.acm.org/ft_gateway.cfm?id=1105800&type=pdf&coll=portal&dl=ACM&CFID=68330711&CFTOKEN=39187329">PDF of full text from ACM</a><br />
<br />
DOI: <a class="url uid" href="http://dx.doi.org/10.1109/SC.2005.53">10.1109/SC.2005.53</a><br />
Tags: <br />
<a class="keyword" rel="tag" href="results.cfm?query=genterm%3A%22Design%22 ..."><br />
Design</a>,<br />
<a class="keyword" rel="tag" href="results.cfm?query=genterm%3A%22Experimentation%22 ...."><br />
Experimentation</a>,<br />
<a class="keyword" rel="tag" href="results.cfm?query=genterm%3A%22Measurement%22..."><br />
Measurement</a>,<br />
<a class="keyword" rel="tag" href="results.cfm?query=genterm%3A%22Performance%22 ..."><br />
Performance</a><br />
<br />
<blockquote class="description">In developing High-Performance Computing (HPC) software, time to solution is an important metric. This metric is comprised of two main components: the human effort required developing the software, plus the amount of machine time required to execute it. To date, little empirical work has been done to study the first component: the human effort required and the effects of approaches and practices that may be used to reduce it. In this paper, we describe a series of studies that address this problem. We instrumented the development process used in multiple HPC classroom environments. We analyzed data within and across such studies, varying factors such as the parallel programming model used and the application being developed, to understand their impact on the development process.<br />
</blockquote><br />
</cite><br />
</nowiki></pre><br />
<br />
<br />
'''Note''' (From [[Discoleo]], Sept. 06)<br />
* sometimes, the citation must include '''Town/Country''' and '''Precise Date/Date Range''', e.g.<br />
** ''Gillespie SH, Dickens A.'' Variation in mutation rate of quinolone resistance in Streptococcus pneumoniae [abstract P06-17A]. In: Abstracts of the 3rd International Symposium on Pneumococci and Pneumococcal Disease (Anchorage, 5-9 May 2002).Washington, DC: American Society of Microbiology, 2002.<br />
** ''Bassetti, M.; Righi, E.; Rebesco, B.; Molinari, MP.; Costa, A.; Fasce, R.; Cruciani, M.; Bassetti, D.; Bobbio Pallavicini, F.'' 44th Annual Interscience Conference on Antimicrobial Agents and Chemotherapy (ICAAC). Washington, DC; 2004. Epidemiological trends in nosocomial candidemia in ICU: A five-year Italian perspective.<br />
** ''Peacock JE, Wade JC, Lazarus HM, et al.'' Ciprofloxacin/piperacillin vs. tobramycin/piperacillin as empiric therapy for fever in neutropenic cancer patients, a randomized, double-blind trial [abstract 373]. In: Program and abstracts of the 37th Interscience Conference on Antimicrob Agents and Chemotherapy (Toronto). Washington, DC: American Society for Microbiology, 1997.<br />
<br />
==== Citing an external website ====<br />
<br />
This is based on a formal citation of a website in the references section of a research paper, but could also be used for in-line links that had added information. Here's the original:<br />
<br />
[25] David Stern, "eprint Moderator Model", http://www.library.yale.edu/scilib/modmodexplain.html (version dated Jan 25, 1999)<br />
<br />
<pre><nowiki><br />
<cite class="citation"><br />
<a class="fn url" href="http://www.library.yale.edu/scilib/modmodexplain.html">eprint Moderator Model</a><br />
<span class="author vcard"><br />
<a href="http://pantheon.yale.edu/~dstern/dsbio.html" class="url fn">David Stern</a><br />
</span> <br />
<abbr class="dtpublished" title="19990125T0000-0500"><br />
Jan 25, 1999<br />
</abbr><br />
</cite><br />
</nowiki></pre><br />
<br />
== Old straw format discussion ==<br />
<br />
Saved here so that I'm not just deleting people's comments.<br />
<br />
<br />
=== Mike straw format suggestion (Deprecated) ===<br />
<br />
In the interests of starting debate and having something concrete to fix, I suggest the following structure for a format. It is probably very incomplete and I claim no microformat expertise. I'm just trying to follow existing patterns. Comments and ridicule are both solicited. -Mike<br />
<br />
'''NOTE:''' This format is here for historical reference. Because it was not based on existing examples, I've deprecated it and contributed examples to Brian's format. If you feel that any missing elements in here should be in the final format, find examples for them and contribute to Brian's schema. Thanks! --[[User:Mike|Mike]] 18:22, 12 Oct 2006 (PDT)<br />
<br />
==== In General ====<br />
<br />
The ''citation'' format is based on a set of fields common to many bibliographic data formats, which are often implied by standard citation display styles but not explicitly marked up in practice on the web.<br />
<br />
==== Schema ====<br />
<br />
The citation schema consists of the following:<br />
<br />
* cite <br />
** title: required, text (class = fn)<br />
** subtitle: optional, text<br />
** authors: optional, use hCard<br />
** publication date: optional<br />
** link(s) to instantiations, optional, url or use rel-enclosure? (class=url)<br />
** UID, optional (for ISBN, DOI - use existing uid class) | permalink<br />
** series (aka volume/issuenum) , optional (''not as sure how to handle these - suggestions?'')<br />
** pages: startpage & endpage, optional, text<br />
** venue, optional (hCard)<br />
** publisher, optional (hCard)<br />
** container: optional (nested hCite)<br />
** abstract, optional (blockquote + class="abstract" ?)<br />
** notes, optional (blockquote + class="notes" ?)<br />
** keywords, optional (rel-tag)<br />
** image, optional (for inclusion inline, unlike the url)<br />
** copyright, optional (rel-license)<br />
** ''what else am I missing?''<br />
*** language, optional<br />
<br />
''Looks good, but I question the use of hCard for names. Due to ambiguity issues, requring hCard would lead to extra markup in order to apply just a name, hence [http://microformats.org/discuss/mail/microformats-discuss/2006-March/003487.html the need for a root element]. We should extract the N optimization of hCard like we did with adr, in order to ease this problem.'' --[[User:RCanine|Ryan Cannon]]<br />
<br />
Perhaps a Retrieved Date or Access Date would be appropriate for citing online resources. For example at http://www.crlt.umich.edu/publinks/facment_biblio.html <br />
you see citations like this<nowiki>:</nowiki><br />
<blockquote><br />
Chief Academic Officers of the Big 12 Universities (2000). Big 12 Faculty Fellowship Program. Retrieved December 20, 2000 from the World Wide Web: http://www.k-state.edu/provost/academic/big12/big12guide.htm.<br />
</blockquote><br />
--[[User:JoeAndrieu|Joe Andrieu]]<br />
<br />
<br />
==== Discussion about citing legal cases ====<br />
<br />
Here's some info I found about citing law:<br />
<br />
I'm not a lawyer, so I'm relying on the published [http://www.legalbluebook.com "blue book" standard], at least the only part of it I can get without paying $25. I'd be happy to hear improvements from experts in the field - how do lawyers mark up references to case law in HTML now?<br />
<br />
From groklaw.net and eff.org, I find mostly just links to PDFs with the name of the case as the link text. Or just this, from EFF:<br />
<pre><nowiki><br />
<h1>The Betamax Case</h1><br />
<h2>Sony Corp. of America v. Universal City Studios, 464 U.S. 417 (1984)</h2><br />
</nowiki></pre><br />
<br />
From an example at the sample bluepages: http://www.legalbluebook.com/pdfs/bluepages.pdf<br />
5 basic components:<br />
*1 name of the case (citation title)<br />
*2 published source in which case may be found (citation containing publication?)<br />
*3 a parenthetical indicating the court and year of decision (citation venue?)<br />
*4 other parenthetical information, if any (citation notes?)<br />
*5 subsequent history of the case, if any (citation notes?)<br />
<br />
Here's two examples from the bluebook. Note that there are very strict rules about abbreviations in that source!<br />
<br />
Holland v. Donnelly, 216 F. Supp. 2d 227, 230 (S.D.N.Y. 2002), aff'd, 324 F.3d 99 (2d Cir. 2003).<br />
<br />
Green v. Georgia, 442 U.S. 95, 97 (1979) (per curiam) (holding that exclusion of relevant evidence at sentencing hearing constitutes denial of due process).<br />
<br />
<br />
<br />
== discussions ==<br />
* [[citation-irc-notes-2006-04-09]]</div>RCaninehttps://microformats.org/wiki/index.php?title=hcard-implied-brainstorming&diff=11122hcard-implied-brainstorming2006-12-08T21:09:55Z<p>RCanine: </p>
<hr />
<div><h1>Implied hCard Brainstorming</h1><br />
<br />
These are ideas for solutions to [[implied-hcard|implied-hcards]]. See [[implied-hcard-examples]] for use cases.<br />
<br />
== Initial ideas ==<br />
<br />
The rule could be similar to:<br />
<br />
If a an element with class=vcard does not have any hCard class names, imply the entire content as an fn field, and attempt to apply the implied "n" optimization.<br />
<br />
Optionally, if the root element has @href, imply a class="url".<br />
<br />
For example:<br />
<br />
<pre><nowiki><br />
<a class="vcard" href="http://ryancannon.com/">Ryan Cannon</a><br />
</nowiki></pre><br />
<br />
becomes<br />
<br />
<pre><nowiki><br />
BEGIN:VCARD<br />
N:Cannon;Ryan;;;<br />
FN:Ryan Cannon<br />
URL:http\://ryancannon.com/<br />
END:VCARD<br />
</nowiki></pre><br />
<br />
All this is possible because it requires an hCard without hCard markup inside.<br />
<br />
This is fairly powerful for a few reasons:<br />
<br />
* It does not require in-depth knowledge of hCard or vCard<br />
* Extraordinarily simple markup<br />
* Provides a smaller barrier-to-entry for microformats that require hCard<br />
<br />
Additionally, the @href could map to different properties based on protocol:<br />
<br />
* <nowiki>[href^='http']</nowiki> would map to <code>url</code><br />
* <nowiki>[href^='mailto']</nowiki> would map to <code>email</code><br />
* <nowiki>[href^='data']</nowiki> would map to <code>photo</code><br />
<br />
--[[User:RCanine|Ryan Cannon]]</div>RCaninehttps://microformats.org/wiki/index.php?title=hcard-implied-examples&diff=11137hcard-implied-examples2006-12-08T20:57:58Z<p>RCanine: </p>
<hr />
<div><h1>Implied hCard examples</h1><br />
<br />
Example implied [[hcard|hCards]], see [[implied-hcard]] for a description and [[implied-hcard-brainstorming]] for ideas.<br />
<br />
== Authors ==<br />
* [http://ryancannon.com/ Ryan Cannon]<br />
<br />
== Instructive Examples ==<br />
<br />
=== References to a person within a blog post ===<br />
<br />
Blog writers specifically, but other writers on the Web as well frequently link to an individual's homepage by linking that persona's name. One example from [http://www.quirksmode.org/blog/archives/2006/12/24ways_hide_and.html Quirksblog]:<br />
<br />
<pre><nowiki><br />
<p>Just as last year, <a href="http://allinthehead.com" class="external">Drew McLellan</a><br />
has created his web geek advent calendar 24ways, in which a few web developers of note share<br />
some tips and tricks to impress your friends. Today my contribution:<br />
<a href="http://24ways.org/2006/hide-and-seek-in-the-head" class="external">Hide and Seek<br />
in the Head</a>.</p><br />
</nowiki></pre><br />
<br />
Displaying as:<br />
<br />
Just as last year, [http://allinthehead.com Drew McLellan] has created his web geek advent calendar 24ways ...<br />
<br />
Changing "Drew McLellan" to an hCard would currently require the at least following additional markup:<br />
<br />
<pre><nowiki><br />
<p>Just as last year,<br />
<span class="vcard"><br />
<a href="http://allinthehead.com" class="external fn url">Drew McLellan</a><br />
</span><br />
has created his web geek advent calendar 24ways...<br />
</p><br />
</nowiki></pre><br />
<br />
If not:<br />
<br />
<pre><nowiki><br />
<p>Just as last year,<br />
<span class="vcard"><br />
<a href="http://allinthehead.com" class="external fn n url"><br />
<span class="given-name">Drew</span><br />
<span class="family-name"><br />
<span class="sort-string">M</span>cLellan<br />
</span><br />
</a><br />
</span><br />
has created his web geek advent calendar 24ways...<br />
</p><br />
</nowiki></pre><br />
<br />
an implied hCard would simplify this construct into a single element with a pre-defined class name.<br />
<br />
=== Simple hCards nested in other Microformats ===<br />
<br />
==== Citation ====<br />
<br />
Brian Suda marked up his citation as<br />
<br />
<pre><nowiki><br />
<p class="author vcard"><a class="fn url" href="http://suda.co.uk/" rel="me">Brian Suda</a></p><br />
</nowiki></pre><br />
<br />
Which could be shortened into a single element and two class names, and not require knowledge of Citation and hCard.<br />
<br />
==== hReview ====<br />
<br />
Many reviewers use a construct similar to [http://www.pacificspirit.com/Restaurants-Vancouver.html David Orchard]:<br />
<br />
Reviews ... are by <span class="reviewer vcard"><span class="fn">David Orchard</span></span></span><br />
<br />
Or the following invalid construct (from [http://jg.typepad.com/ciel/2006/02/daniel_bouluds_.html Joan], listed on the [[hreview-examples-in-wild|hReview Examples in the wild]]:<br />
<br />
<pre><nowiki><br />
<span class="reviewer fn"><A HREF="http://jg.typepad.com/ciel">Joan Gelfand</A></span><br />
</nowiki></pre><br />
<br />
An implied hCard would simplify the markup and prevent (some) user error.<br />
<br />
==== hAtom ====<br />
<br />
The Strangelove Wordpress ([http://www.whump.com/sandbox/Strangelove.zip zip]) theme creates the following construct for authors:<br />
<br />
<pre><nowiki><br />
<span class="vcard author"><a class="url fn" href="http://www.example.com/author">Nickname</a></span><br />
</nowiki></pre><br />
<br />
While the [http://www.plaintxt.org/themes/sandbox/ Sandbox] theme creates:<br />
<br />
<pre><nowiki><br />
<span class="entry-author author vcard">By<br />
<a class="url fn" href="http://www.example.com/author" title="View all posts by Nickname">Nickname</a><br />
</span><br />
</nowiki></pre><br />
<br />
Implied hCards would simplify hAtom implementations for developers.</div>RCaninehttps://microformats.org/wiki/index.php?title=hcard-implied-brainstorming&diff=11121hcard-implied-brainstorming2006-12-08T20:57:00Z<p>RCanine: </p>
<hr />
<div><h1>Implied hCard Brainstorming</h1><br />
<br />
These are ideas for solutions to [[implied-hcard|implied-hcards]]. See [[implied-hcard-examples]] for use cases.<br />
<br />
== Initial ideas ==<br />
<br />
The rule could be similar to:<br />
<br />
If a an element with class=vcard does not have any hCard class names, imply the entire content as an fn field, and attempt to apply the implied "n" optimization.<br />
<br />
Optionally, if the root element has @href, imply a class="url".<br />
<br />
For example:<br />
<br />
<pre><nowiki><br />
<a class="vcard" href="http://ryancannon.com/">Ryan Cannon</a><br />
</nowiki></pre><br />
<br />
becomes<br />
<br />
<pre><nowiki><br />
BEGIN:VCARD<br />
N:Cannon;Ryan;;;<br />
FN:Ryan Cannon<br />
URL:http\://ryancannon.com/<br />
END:VCARD<br />
</nowiki></pre><br />
<br />
All this is possible because it requires an hCard without hCard markup inside.<br />
<br />
This is fairly powerful for a few reasons:<br />
<br />
* It does not require in-depth knowledge of hCard or vCard<br />
* Extraordinarily simple markup<br />
* Provides a smaller barrier-to-entry for microformats that require hCard<br />
<br />
--[[User:RCanine|Ryan Cannon]]</div>RCaninehttps://microformats.org/wiki/index.php?title=hcard-implied&diff=11126hcard-implied2006-12-08T20:50:16Z<p>RCanine: </p>
<hr />
<div><h1>Implied hCard</h1><br />
<br />
Implied hCards attempt to streamline creation and markup for simple hCards by assuming information from common design patterns.<br />
<br />
== Authors ==<br />
* [http://ryancannon.com/ Ryan Cannon]<br />
<br />
== Why? ==<br />
<br />
As microformats grow and emerge, the barrier to entry for writing them increases. Already, compound microformats such as hAtom, hResume and hReview are comprised of data from hCard, hCal, and rel-tag, and writing to the former requires knowledge of the latter even if the constructs used are quite simple. In addition, adding microformats to a Web page often requires adding a significant amount of tags to code, which often have to be added (time-consumingly) by hand. For example:<br />
<br />
<pre><nowiki><br />
<a href="http://www.example.com/">John Doe</a><br />
</nowiki></pre><br />
<br />
quickly becomes:<br />
<br />
<pre><nowiki><br />
<span class="vcard"><br />
<a class="url fn n" href="http://www.example.com/"><br />
<span class="given-name">John</span><br />
<span class="family-name"><br />
<span class="sort-string">D</span>oe<br />
</span><br />
</a><br />
</span><br />
</nowiki></pre><br />
<br />
Which amounts to an almost 500% increase in code. For two words and a <abbr>URL</abbr>.<br />
<br />
* For more examples, see [[implied-hcard-examples]]<br />
* For ideas refer to [[implied-hcard-brainstorming]]</div>RCaninehttps://microformats.org/wiki/index.php?title=hcard-implied-examples&diff=11119hcard-implied-examples2006-12-08T20:43:09Z<p>RCanine: </p>
<hr />
<div><h1>Implied hCard examples</h1><br />
<br />
Example implied [[hcard|hCards]].<br />
<br />
== Authors ==<br />
* [http://ryancannon.com/ Ryan Cannon]<br />
<br />
== Instructive Examples ==<br />
<br />
=== References to a person within a blog post ===<br />
<br />
Blog writers specifically, but other writers on the Web as well frequently link to an individual's homepage by linking that persona's name. One example from [http://www.quirksmode.org/blog/archives/2006/12/24ways_hide_and.html Quirksblog]:<br />
<br />
<pre><nowiki><br />
<p>Just as last year, <a href="http://allinthehead.com" class="external">Drew McLellan</a><br />
has created his web geek advent calendar 24ways, in which a few web developers of note share<br />
some tips and tricks to impress your friends. Today my contribution:<br />
<a href="http://24ways.org/2006/hide-and-seek-in-the-head" class="external">Hide and Seek<br />
in the Head</a>.</p><br />
</nowiki></pre><br />
<br />
Displaying as:<br />
<br />
Just as last year, [http://allinthehead.com Drew McLellan] has created his web geek advent calendar 24ways ...<br />
<br />
Changing "Drew McLellan" to an hCard would currently require the at least following additional markup:<br />
<br />
<pre><nowiki><br />
<p>Just as last year,<br />
<span class="vcard"><br />
<a href="http://allinthehead.com" class="external fn url">Drew McLellan</a><br />
</span><br />
has created his web geek advent calendar 24ways...<br />
</p><br />
</nowiki></pre><br />
<br />
If not:<br />
<br />
<pre><nowiki><br />
<p>Just as last year,<br />
<span class="vcard"><br />
<a href="http://allinthehead.com" class="external fn n url"><br />
<span class="given-name">Drew</span><br />
<span class="family-name"><br />
<span class="sort-string">M</span>cLellan<br />
</span><br />
</a><br />
</span><br />
has created his web geek advent calendar 24ways...<br />
</p><br />
</nowiki></pre><br />
<br />
an implied hCard would simplify this construct into a single element with a pre-defined class name.<br />
<br />
=== Simple hCards nested in other Microformats ===<br />
<br />
==== Citation ====<br />
<br />
Brian Suda marked up his citation as<br />
<br />
<pre><nowiki><br />
<p class="author vcard"><a class="fn url" href="http://suda.co.uk/" rel="me">Brian Suda</a></p><br />
</nowiki></pre><br />
<br />
Which could be shortened into a single element and two class names, and not require knowledge of Citation and hCard.<br />
<br />
==== hReview ====<br />
<br />
Many reviewers use a construct similar to [http://www.pacificspirit.com/Restaurants-Vancouver.html David Orchard]:<br />
<br />
Reviews ... are by <span class="reviewer vcard"><span class="fn">David Orchard</span></span></span><br />
<br />
Or the following invalid construct (from [http://jg.typepad.com/ciel/2006/02/daniel_bouluds_.html Joan], listed on the [[hreview-examples-in-wild|hReview Examples in the wild]]:<br />
<br />
<pre><nowiki><br />
<span class="reviewer fn"><A HREF="http://jg.typepad.com/ciel">Joan Gelfand</A></span><br />
</nowiki></pre><br />
<br />
An implied hCard would simplify the markup and prevent (some) user error.<br />
<br />
==== hAtom ====<br />
<br />
The Strangelove Wordpress ([http://www.whump.com/sandbox/Strangelove.zip zip]) theme creates the following construct for authors:<br />
<br />
<pre><nowiki><br />
<span class="vcard author"><a class="url fn" href="http://www.example.com/author">Nickname</a></span><br />
</nowiki></pre><br />
<br />
While the [http://www.plaintxt.org/themes/sandbox/ Sandbox] theme creates:<br />
<br />
<pre><nowiki><br />
<span class="entry-author author vcard">By<br />
<a class="url fn" href="http://www.example.com/author" title="View all posts by Nickname">Nickname</a><br />
</span><br />
</nowiki></pre><br />
<br />
Implied hCards would simplify hAtom implementations for developers.</div>RCaninehttps://microformats.org/wiki/index.php?title=citation-brainstorming&diff=6164citation-brainstorming2006-05-01T22:19:23Z<p>RCanine: /* Schema */</p>
<hr />
<div><h1> Citation Brainstroming </h1><br />
<br />
__TOC__<br />
<br />
== Contributors ==<br />
<br />
* ...<br />
* ... (a bunch of good folks!)<br />
* Tantek Çelik<br />
* Tim White<br />
* Michael McCracken<br />
<br />
== See also ==<br />
* [[citation]]<br />
* [[citation-examples]]<br />
* [[citation-formats]]<br />
* [[citation-faq]]<br />
<br />
== Use Cases ==<br />
<br />
To focus the discussion, please add use cases below that will help show what problems the citation microformat will be solving.<br />
<br />
I've included two, focusing on consuming information - I've assumed that use cases for generating microformatted content would just involve the desire to enable your content to be consumed better, but I'm interested to see if there's something I'm missing here -Mike<br />
<br />
=== Acquiring reference information from the web ===<br />
<br />
A user either finds an author's papers page, or is viewing the results of a search and would like to import the information about the displayed papers into their local reference database, for the purposes of cataloging things they've read, adding notes, and using the information to generate later citations, potentially in other forms, such as BibTeX or Docbook, for inclusion in a publication of their own.<br />
<br />
Notes: In this case, it isn't important to the user what format the citation takes as displayed on the page where they find it. What *is* important is that it contains enough information to allow generation of the format they will ultimately re-publish it in. This implies that it may be worthwhile to err a little on the side of verbosity.<br />
<br />
Also, links to downloadable full representations of the cited work are very important - e.g. a link to the PDF of a journal article, or to a music file.<br />
<br />
=== Subscribing to reading lists, periodicals, etc ===<br />
<br />
I would like to be able to leverage my news aggregator with hAtom to subscribe to a remote source for citation information, for example:<br />
<br />
* a reading list for a seminar<br />
* The publication list for a conference (e.g., subscribe to SIGGRAPH and see the updated conference proceedings every year)<br />
* the issues of a journal<br />
* a particular research group or researcher's publications<br />
* Not just research: a popular author's publications (e.g., [http://www.gladwell.com/archive.html Malcolm Gladwell's Archive])<br />
<br />
=== Aggregating reading lists and reviews ===<br />
<br />
A citation microformat-specific aggregator could provide a decentralized version of [http://citeulike.org/ CiteULike]. Libraries, authors, research groups, and publishers could mark up their collections, while other people on weblogs or review sites could add tags and reviews.<br />
<br />
At least, having a well-adopted microformat would make writing tools like CiteULike much better, since it relies in some cases on screen-scraping publisher web-sites.<br />
<br />
== Original hBib Discussion ==<br />
<br />
During the WWW2005 Developer's Day [[microformats]] track, Rohit Khare gave a [[presentations|presentation]] where he discussed the microformats [[process]], and then did a quick demonstration wherein a bunch of us got on a shared Subethaedit document, and brainstormed some thoughts on what an "hBib" bibliography citation microformat would look like. Rohit placed the [http://cnlabs.commerce.net/~rohit/hBib%20Discussion.html document on his Commercenet site].<br />
<br />
* http://cnlabs.commerce.net/~rohit/hBib%20Discussion.html<br />
<br />
''An attempt to summarize and inline the linked document follows. -Mike''<br />
<br />
Two major goals were outlined by the group:<br />
<br />
* Avoid re-keying references<br />
* Adapt to new journal styles by changing CSS<br />
<br />
The fundamental problem was discussed in terms of display - the ability to transform XHTML+hBib into the many journal-specific formats. For example, how to display "et.al" when all authors are present in the source, and how to re-order the elements if a style defines a set order of elements that conflicts with the ordering in the source. Using hCard for authors was agreed on, and the beginnings of an example were shown.<br />
<br />
== XHTML Structure ==<br />
With my exprience working X2V and hCa* has taught me what elememts are easy to find and which are not. Since the Citation microformat is very new it is possible to not make a lot of the same errors twice and to make things easier for extracting application to find and imply certain properties.<br />
<br />
* There should be some sort of 'root node' that implies all child elements are for the Citation microformat.<br />
* Since most people will have multiple Citation there should be away to represent each Citation object as a unqiue block independant of another. This is to keep the parse from finding 'author' and applying to all citations. Each citation should be in a container (class="???") that scoped from others.<br />
* Perhaps class="hcite" with <code>&lt;cite&gt;</code> recommended as the root element. E.g. <code>&lt;cite class="hcite"&gt;</code><br />
<br />
== Citation vs. [[media-info]] ==<br />
<br />
What distinguishes a cite from say [[media-info]] (e.g. [[media-info-examples]]) is that a cite is a reference to something explicitly external to the current piece of content or document, whereas [[media-info]] describes information about content embedded or inline in the current document.<br />
<br />
== Semantic Meaning ==<br />
One of the guiding priniciple of Microformats is to use the most semantically rich element to describe each node (Point 2 of Semantic XHTML Design Principles: Use the most accurately precise semantic XHTML building block for each object etc). Since we are dealing with HTML and citations, several elements are candidates to be used to enrich the semantic meaning. [http://www.w3.org/TR/REC-html40/struct/text.html CITE, BLOCKQUOTE, Q, A], (are there more?)<br />
<br />
The [[citation-brainstorming|Citation Brainstorming Page]] has a few development and ideas about how to give another person credit for a link. Some of the semantic ideas behind their choices of tags can be applied to a full bibliographic type reference. ''Does this sentence make sense only historically? -Mike''<br />
<br />
== OCLC's WorldCat for titles == <br />
Question: what about using something like OCLC's [http://www.oclc.org/worldcat/open/isbnissnlinking/default.htm WorldCat] for linking titles? - Tim White<br />
<br />
== This and That ==<br />
After reading through alot of different citation encoding formats, i noticed that each format was being used in onw of two ways. It was either to describe the Current page (THIS.PAGE) or being used to encode references that point to external resources (THAT.PAGE)<br />
<br />
The informatation being encoded was identical for both resources (author, date, name, etc) they just reference different things. For this microformat, i'm not sure if we want to try to solve both problems, or just one? The meta tags in the head element would be the ideal place for information about the THIS.PAGE, but that is not in following with the ideals of microformats where information is human-readable. The THAT.PAGE idea where a list of references is at the end of a document in the form of a bibliography is more inline with the ideals of a microformat where the data is human-readable. That doesn't mean that data about the current document shouldn't be human-readable, so some of the same properties used to reference extermal resources can be used for the current document (THIS.PAGE). To do this a different root item could be used and transforming applications could either extract the citation data about the current page, or information about this page's references.<br />
<br />
This is open for discussion, but either way, i believe that the properties used to describe a page will be the same for both THIS and THAT. [http://suda.co.uk/ brian suda]<br />
<br />
== More on This and That ==<br />
<br />
Citation microformats are being explored as a possibility for citing genealogical information at [http://eatslikeahuman.blogspot.com Dan Lawyer's blog].<br />
<br />
This is a case where frequently the citation would refer to (THIS.PAGE), but would have nested within it a reference to (THAT.PAGE), possibly a few levels deep. For instance, a web page might contain data extracted from a microfilm of a census. The citation would need to include information about the web page, information about the microfilm, and information about the census. Genealogical citations are expected to include the repository (where can this book or microfilm be found. Is this the same as ''venue''?). So, at each level the information should contain the repository of the referenced item. A nesting (recursive) mechanism for citation microformats would be useful in this case. Is this the function of the "container" element in the Straw Format?<br />
<br />
== Date Formatting ==<br />
Since microformats are all about re-use and the accepted way to encode Date-Time has been pretty much settled, then this is a good place to start when dealing with all the different date citation types. <br />
<br />
These are all the different fields from various citation formats that are of temporal nature:<br />
* Date (available | created | dateAccepted | dateCopyrighted | dateSubmitted | issued | modified | valid)<br />
* originInfo/dateIssued<br />
* originInfo/dateCreated<br />
* originInfo/dateCaptured<br />
* originInfo/dateOther<br />
* month<br />
* year<br />
* Copyright Year<br />
* Date - Generic<br />
* Date of Confernce<br />
* Date of Publication<br />
* Date of update/revisou/issuance of database record<br />
* Former Date<br />
* Entry Date for Database Record<br />
* Database Update<br />
* Year of Publication<br />
<br />
There are several common properties across several citation domains and will certainly be in the citation microformat, the unique instances will need further consideration, otherwise there could be no end to posiblities. <br />
<br />
There are also several properties (year, month, Year of publication) that can be extracted from another source. Therefore, if you only encode a more specific property such as; Date of Publication, you can extract the 'year of publication' from that. Since the date-time format we are modeling after is the ISO date-time format, just the Year portion is an acceptable date. So if you ONLY know the year of publication, the you can form a valid 'Date of Publication' as a microformat (which inturn is a valid 'year of publication') - you milage may vary when it comes to importing into citation applications.<br />
<br />
...<br />
<br />
It seems to me that these can be collapsed to maybe one or two different date properties. As far as the specific human readable formatting of the date, that can be chosen per whatever the presentation style guide says, and the [[datetime-design-pattern]] used to simplify the markup. - Tantek<br />
<br />
<br />
<br />
<br />
== Tags ==<br />
Some of the citation formats has a place for 'keywords' or 'generic tags', etc. This might be a good place to re-use the [http://microformats.org/wiki/rel-tag RelTag microformat]. The downside would be that they are then forced to be links, which might be the correct way to mark-up these terms.<br />
<br />
<br />
== MARC / MODS / Dublin Core ==<br />
<br />
The MODS ([http://www.loc.gov/standards/marcxml/Sandburg/sandburgmods.xml example]) and Dublin Core ([http://www.loc.gov/standards/marcxml/Sandburg/sandburgdc.xml example]) transformations of MARC21 may contain some useful ideas.<br />
<br />
Here's a first attempt at rewriting the linked examples in XHTML (written in response to a [http://microformats.org/discuss/mail/microformats-discuss/2005-December/002438.html mailing list query about encoding book information with microformats]):<br />
<br />
<pre><nowiki><br />
<div class="book" lang="en"><br />
<h3 class="fn">Arithmetic /</h3><br />
<p>By <span class="creator"><span class="fn">Sandburg, Carl</span>,<br />
<span class="date">1878-1967</span></span>,<br />
and <span class="illustrator">Rand, Ted</span></p><br />
<p>Publisher: <span class="publisher"><span class="fn">Harcourt Brace Jovanovich</span>,<br />
<span class="locality">San Diego</span></span></p><br />
<p>Published: <span class="issued">1993</span></p><br />
<p class="description">A poem about numbers and their characteristics. Features<br />
anamorphic, or distorted, drawings which can be restored to normal by viewing<br />
from a particular angle or by viewing the image's reflection in the provided<br />
Mylar cone.</p><br />
<p class="note">One Mylar sheet included in pocket.</p><br />
<p>Subjects:</p><br />
<ul><br />
<li class="subject">Arithmetic</li><br />
<li class="subject">Children's poetry, American.</li><br />
<li class="subject">Arithmetic</li><br />
<li class="subject">American poetry</li><br />
<li class="subject">Visual perception</li><br />
</ul><br />
</div><br />
</nowiki></pre><br />
<br />
== Basic Citation Stuctures ==<br />
There are basic structures to any citation, this is an overview of some of the types<br />
[http://www.users.muohio.edu/darcusb/misc/citations-spec.html http://www.users.muohio.edu/darcusb/misc/citations-spec.html]<br />
<br />
== Brian's Straw format ==<br />
<br />
=== implied schema (examples) ===<br />
+ publisher<br />
+ language<br />
+ description<br />
+ title<br />
+ creator<br />
+ volume<br />
+ issue<br />
+ page <br />
+ edition<br />
+ identifier<br />
+ tags<br />
+ format<br />
+ date published<br />
+ copyright<br />
- audience<br />
<br />
=== implied schema (formats) ===<br />
+ publisher<br />
+ language<br />
+ description<br />
+ title<br />
+ creator<br />
+ volume<br />
+ pages<br />
+ edition<br />
+ issue<br />
+ identifier<br />
+ tags<br />
+ format<br />
+ date published<br />
+ date copyrighted<br />
- subtitle<br />
- image <br />
- excerpt<br />
- index terms<br />
- series title<br />
- publication<br />
- journal<br />
- part (1 of X)<br />
<br />
UNION of the two schemas<br />
+ (PLUS) means common properties<br />
- (MINUS) means unique to the schema<br />
<br />
=== Example ===<br />
<pre><br />
<nowiki><br />
<ul class="bibliography"><br />
<li class="citation" xml:lang="en-gb"><br />
<br />
<!-- publisher data as hCard--><br />
<div class="publisher vcard"><br />
<span class="fn org">ABC Publishing Co.</span><br />
<span class="country-name">United Kingdom</span><br />
...<br />
</div><br />
<br />
<!-- author(s) data as hCard --><br />
<div class="creator vcard"><br />
<span class="fn n"><span class="given-name">John <span class="family-name">Doe</span></span><br />
...<br />
</div><br />
<br />
<!-- location data --><br />
<span class="title">Foobar!</span><br />
<span class="description">World Class Book about foobar</span><br />
<span class="volume">1</span><br />
<span class="issue">1</span><br />
<span class="edition">1</span><br />
<span class="pages">1-10</span><br />
<span class="format">article</span><br />
<br />
<!-- differed to the UID debate --><br />
<span class="identifier">12345678</span><br />
<br />
<!-- keywords --><br />
<span class="keyword">foo</span><br />
<span class="keyword">bar</span><br />
<br />
<!-- date properties --><br />
Published <abbr class="dtpublished" title="20060101">January 1st 1006</abbr><br />
Copyright <abbr class="copyright" title="20060101">2006</abbr><br />
</li><br />
...<br />
</ul><br />
<br />
<p class="citation">Have you read <span class="title"><abbr title="book" class="format">Foo Bar</abbr></span>? <br />
It was written by <span class="author vcard"><span class="fn">John Doe</span></span>. <br />
It only came out a <abbr class="dtpublished" title="20060101">few months ago</abbr></p><br />
</nowiki><br />
</pre><br />
<br />
Note: the "format" property above is incorrect. Format would refer more the physical characteristics of an item, rather than its type or genre (e.g. "article", "book", etc.). I'd rather have the main class for the li be "article" in this context, than the fairly meaningless "citation." Of course, one could have both, which would be fine too. -- bruce<br />
<br />
== Mike straw format suggestion ==<br />
<br />
In the interests of starting debate and having something concrete to fix, I suggest the following structure for a format. It is probably very incomplete and I claim no microformat expertise. I'm just trying to follow existing patterns. Comments and ridicule are both solicited. -Mike<br />
<br />
=== In General ===<br />
<br />
The ''citation'' format is based on a set of fields common to many bibliographic data formats, which are often implied by standard citation display styles but not explicitly marked up in practice on the web.<br />
<br />
=== Schema ===<br />
<br />
The citation schema consists of the following:<br />
<br />
* cite <br />
** title: required, text (class = fn)<br />
** subtitle: optional, text<br />
** authors: optional, use hCard<br />
** publication date: optional<br />
** link(s) to instantiations, optional, url or use rel-enclosure? (class=url)<br />
** UID, optional (for ISBN, DOI - use existing uid class) | permalink<br />
** series (aka volume/issuenum) , optional (''not as sure how to handle these - suggestions?'')<br />
** pages: startpage & endpage, optional, text<br />
** venue, optional (hCard)<br />
** publisher, optional (hCard)<br />
** container: optional (nested hCite)<br />
** abstract, optional (blockquote + class="abstract" ?)<br />
** notes, optional (blockquote + class="notes" ?)<br />
** keywords, optional (rel-tag)<br />
** image, optional (for inclusion inline, unlike the url)<br />
** copyright, optional (rel-license)<br />
** ''what else am I missing?''<br />
*** language, optional<br />
<br />
''Looks good, but I question the use of hCard for names. Due to ambiguity issues, requring hCard would lead to extra markup in order to apply just a name, hence [http://microformats.org/discuss/mail/microformats-discuss/2006-March/003487.html the need for a root element]. We should extract the N optimization of hCard like we did with adr, in order to ease this problem.'' --[[User:RCanine|Ryan Cannon]]<br />
<br />
=== Examples ===<br />
<br />
The following are translations into the ''citation'' format.<br />
<br />
Note: some of these are just placeholders right now. Please feel free to fill them in!<br />
<br />
==== Citing Private Communication ====<br />
* published-date seems a weird fit, but it works...<br />
private communication, Michael Jordan, May 2004<br />
<br />
Needs a formatted example.<br />
<br />
==== Citing Legal Cases ====<br />
Needs an example. Here's some info I found about citing law:<br />
<br />
I'm not a lawyer, so I'm relying on the published [http://www.legalbluebook.com "blue book" standard], at least the only part of it I can get without paying $25. I'd be happy to hear improvements from experts in the field - how do lawyers mark up references to case law in HTML now?<br />
<br />
From groklaw.net and eff.org, I find mostly just links to PDFs with the name of the case as the link text. Or just this, from EFF:<br />
<pre><nowiki><br />
<h1>The Betamax Case</h1><br />
<h2>Sony Corp. of America v. Universal City Studios, 464 U.S. 417 (1984)</h2><br />
</nowiki></pre><br />
<br />
From an example at the sample bluepages: http://www.legalbluebook.com/pdfs/bluepages.pdf<br />
5 basic components:<br />
*1 name of the case (citation title)<br />
*2 published source in which case may be found (citation containing publication?)<br />
*3 a parenthetical indicating the court and year of decision (citation venue?)<br />
*4 other parenthetical information, if any (citation notes?)<br />
*5 subsequent history of the case, if any (citation notes?)<br />
<br />
Here's two examples from the bluebook. Note that there are very strict rules about abbreviations in that source!<br />
<br />
Holland v. Donnelly, 216 F. Supp. 2d 227, 230 (S.D.N.Y. 2002), aff'd, 324 F.3d 99 (2d Cir. 2003).<br />
<br />
Green v. Georgia, 442 U.S. 95, 97 (1979) (per curiam) (holding that exclusion of relevant evidence at sentencing hearing constitutes denial of due process).<br />
<br />
==== Citing a Book ====<br />
<br />
needs an example<br />
<br />
==== Citing a journal article ====<br />
<br />
needs an example <br />
<br />
==== Citing a magazine article ====<br />
<br />
needs an example<br />
<br />
==== Citing a Patent ====<br />
<br />
Patents are often just cited by number. Here's a citation that accomplishes the same thing with some extra information:<br />
<br />
<pre><nowiki><br />
<cite class="citation"><br />
<a class="fn url" href="http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/search-bool.html&r=3&f=G&l=50&co1=AND&d=ptxt&s1=tevanian&OS=tevanian&RS=tevanian">US Patent #6,704,928</a><br />
<span class="author vcard">Richard Shann</span><br />
<abbr class="dtpublished" title="20000828T0000-0500">August 28, 2000</abbr><br />
<blockquote class="abstract"><br />
An executable program is prepared from a plurality of object code modules, at least one of the object code modules including section data specifying a plurality of code sequences each associated with relocation instructions identifying condition parameters. Only one of the code sequences is selected for inclusion in the executable program, determined by whether the condition for that parameter is satisfied. A linker for preparing the executable program includes a stack, a relocation module for reading the relocations, carrying out the relocation operations and selecting code sequences for inclusion in the executable program in dependence on values taken from the stack, a section data module for holding section data which is subject to the relocation operations, and a program forming module for preparing executable programs. Also disclosed is a method of assembling an object code module such that the assembled object code module includes the conditional code sequences.</blockquote><br />
</cite><br />
</nowiki></pre><br />
<br />
==== Citing a conference publication====<br />
<br />
Based on the following reference, plus some more information from the ACM site and a little of my own input (the tags)<br />
<br />
L. Hochstein, J. Carver, F. Shull, S. Asgari, V. Basili, J. K. Hollingsworth, and M. Zelkowitz, “Hpc programmer productivity: A case study of novice hpc programmers,” in Proceedings of ACM/IEEE Supercomputing Conference, 2005.<br />
<br />
<pre><nowiki><br />
<cite class="citation"><br />
<span class="author vcard">Lorin Hochstein</span>,<br />
<span class="author vcard"> Jeff Carver </span>,<br />
<span class="author vcard"> Forrest Shull </span>,<br />
<span class="author vcard"> Sima Asgari</span>,<br />
<span class="author vcard"> Victor Basili</span>,<br />
<span class="author vcard"> Jeffrey K. Hollingsworth</span>, and <br />
<span class="author vcard"> Marv Zelkowitz</span>,<br />
<a class="fn url" href="http://dx.doi.org/10.1109/SC.2005.53">HPC Programmer Productivity: A Case Study of Novice HPC Programmers</a>.<br />
<cite class="container citation"><br />
<a class="fn url" href="">Proceedings of ACM/IEEE Supercomputing Conference</a><br />
<abbr class="dtpublished" title="20051126T0000-0800">2005</abbr><br />
</cite><br />
page <span class="startpage">35</span><br />
<div class="publisher vcard"><br />
<span class=" fn">IEEE Computer Society<br />
</span><br />
<div class="adr"><br />
<span class="locality">Washington</span>,<br />
<span class="region">DC</span><br />
</div><br />
</div><br />
<a class="url instantiation" href="http://portal.acm.org/ft_gateway.cfm?id=1105800&type=pdf&coll=portal&dl=ACM&CFID=68330711&CFTOKEN=39187329">PDF of full text from ACM</a><br />
<br />
DOI: <a class="url uid" href="http://dx.doi.org/10.1109/SC.2005.53">10.1109/SC.2005.53</a><br />
Tags: <a href="http://citeulike.org/tag/productivity" rel="tag">productivity</a>, <a href="http://citeulike.org/tag/hpc" rel="tag">hpc</a>, <a href="http://citeulike.org/tag/performance" rel="tag">performance</a><br />
<blockquote class="abstract">In developing High-Performance Computing (HPC) software, time to solution is an important metric. This metric is comprised of two main components: the human effort required developing the software, plus the amount of machine time required to execute it. To date, little empirical work has been done to study the first component: the human effort required and the effects of approaches and practices that may be used to reduce it. In this paper, we describe a series of studies that address this problem. We instrumented the development process used in multiple HPC classroom environments. We analyzed data within and across such studies, varying factors such as the parallel programming model used and the application being developed, to understand their impact on the development process.<br />
</blockquote><br />
</cite><br />
</nowiki></pre><br />
<br />
==== Citing an external website ====<br />
<br />
This is based on a formal citation of a website in the references section of a research paper, but could also be used for in-line links that had added information. Here's the original:<br />
<br />
[25] David Stern, "eprint Moderator Model", http://www.library.yale.edu/scilib/modmodexplain.html (version dated Jan 25, 1999)<br />
<br />
<pre><nowiki><br />
<cite class="citation"><br />
<a class="fn url" href="http://www.library.yale.edu/scilib/modmodexplain.html">eprint Moderator Model</a><br />
<span class="author vcard"><br />
<a href="http://pantheon.yale.edu/~dstern/dsbio.html" class="url fn">David Stern</a><br />
</span> <br />
<abbr class="dtpublished" title="19990125T0000-0500"><br />
Jan 25, 1999<br />
</abbr><br />
</cite><br />
</nowiki></pre><br />
<br />
== discussions ==<br />
<br />
* [[citation-irc-notes-2006-04-09]]</div>RCaninehttps://microformats.org/wiki/index.php?title=User:RCanine&diff=21013User:RCanine2006-04-20T23:39:16Z<p>RCanine: </p>
<hr />
<div>== Ryan Cannon ==<br />
<br />
Attempting to contribute where I can. I am most interested in [[citation]] microformat. <br />
<br />
Please contact me via my [http://RyanCannon.com/contact/ Web Site].</div>RCaninehttps://microformats.org/wiki/index.php?title=User:RCanine&diff=5963User:RCanine2006-04-20T23:38:40Z<p>RCanine: </p>
<hr />
<div>== Ryan Cannon ==<br />
<br />
Attempting to contribute where I can. I am most interested in [[citation]] microformat. <br />
<br />
Please contact me via my <a href="http://RyanCannon.com/contact/">Web Site</a>.</div>RCaninehttps://microformats.org/wiki/index.php?title=User:RCanine&diff=5962User:RCanine2006-04-20T23:38:04Z<p>RCanine: /* Ryan Cannon */</p>
<hr />
<div>== Ryan Cannon ==<br />
<br />
Attempting to contribute where I can. I am most interested in [[citation]] microformat. <br />
<br />
Please contact me via my [Web Site|http://RyanCannon.com/contact/].</div>RCaninehttps://microformats.org/wiki/index.php?title=User:RCanine&diff=5961User:RCanine2006-04-20T23:26:38Z<p>RCanine: </p>
<hr />
<div>== Ryan Cannon ==<br />
<br />
Attempting to contribute where I can.<br />
<br />
<br />
{{Vandal}}</div>RCaninehttps://microformats.org/wiki/index.php?title=workofart-brainstorming&diff=16257workofart-brainstorming2006-04-20T23:25:57Z<p>RCanine: /* What about citation? */</p>
<hr />
<div>= Work of Art Brainstorming =<br />
<br />
This page is for brainstorming about ideas, proposals, constraints, and requirements for a work of art microformat.<br />
<br />
This is part of a community effort to create a [[work-of-art]] microformat. (See also: [[workofart-examples]], [[workofart-formats]].)<br />
<br />
<br />
== Participants ==<br />
<br />
* [[User:TimG| Tim Gambell]]<br />
* Samantha Orme<br />
<br />
<br />
== The Problem ==<br />
<br />
Many art museums use metadata to describe the works of art in their collections. However, the presentation of works of art on the web often does not benefit from that formalized categorization work. We'd like to develop a xhtml markup standard for the presentation of works of art on the web.<br />
<br />
<br />
== Use Cases ==<br />
<br />
Why bother with a microformat for works of art? What problems will it enable us able to solve? What new tools will it enable us to build?<br />
<br />
<br />
=== The Metamuseum ===<br />
<br />
A work of art microformat turns the art on museum websites into the building blocks of a web based "metamuseum" -- an interface to the works of art on the web.<br />
<br />
<br />
=== The Work of Art Aggregator (+ XSLT = Flash Cards) ===<br />
<br />
"I'm a college student who takes art history courses. At many times I have been presented with the problem of creating flash <br />
cards for the exams in these courses. How much time I could have saved with a work-of-art aggregator, and an xslt sheet which could produce printable flashcards automatically from the wide range of art sites out in the wild." -- from [http://microformats.org/discuss/mail/microformats-discuss/2006-March/003422.html this post] on the microformats [http://microformats.org/mailman/listinfo/microformats-discuss/ discuss list]<br />
<br />
<br />
=== Research (and Publicity for Smaller Collections?) ===<br />
<br />
"I mentioned previously that I would be shortly redesigning an art gallery's website making heavy use of microformats. I was just informed that they want to reproduce photographs of all the art and sculpture from each artist for the purposes of working with clientelle in making an informed decision about the purchase of art work. With a microformat as a guide to "best practices" such a catalogue could easily be collected into a searchable database." -- from [http://microformats.org/discuss/mail/microformats-discuss/2006-March/003422.html this post] on the microformats [http://microformats.org/mailman/listinfo/microformats-discuss/ discuss list]<br />
<br />
<br />
=== Galleries ===<br />
<br />
I'd guess that it's more common for multiple works of art to be viewed on a single web page than it is for a single work to be viewed on a single page. In real life, multiple works of art can be combined to make a gallery. The work of art microformat should be designed so that it's easy to combine multiple xhtml works of art into an xhtml gallery (perhaps using something like the hAtom format to tie the pieces together).<br />
<br />
<br />
== Discussion ==<br />
<br />
<br />
=== What should work of art be based on? ===<br />
<br />
* What is the best of the existing metadata schema to use as the basis for the work of art microformat?<br />
<br />
** Consensus seems to be building around using [[citation]] for the basic terms. See the discussion below. -- [[User:TimG | Tim]]<br />
<br />
<br />
=== Integration of other microformats ===<br />
<br />
* What is the best way to integrate existing microformats into the work of art microformat? For example, would it be appropriate to use the hCard microformat to identify the artist? To identify the work of art's location?<br />
<br />
<br />
=== What about [[citation]]? ===<br />
<br />
* [[User:RCanine|Ryan Cannon]] proposes that work-of-art could be produced as a special case of the [[citation]] microformat.<br />
<br />
* I propose that work-of-art should be (more specifically) an ''extension'' of the [[citation]] microformat. I propose that the goal of work-of-art be to create a simplified version of CDWA, whose core components are those parts of CDWA that are most commonly used when representing a work of art online. However, work-of-art should be extensible such that any work of art may be accomodated. Essentially, work-of-art should strongly encourage the use of its core components (for consistency), but allow additional elements for those cases in which they are strictly necessary. Opinions on the utility and/or drawbacks of being all-inclusive are requested. [ [http://www.19clicks.com Samantha Orme] ] <br />
** One of the core principles behind microformats is the reuse of existing standards. [[hCard]], for example, is almost a 1:1 reimplimentation of the vcard standard. The proposal that we base this format on [[citation]] raises the question: is it better to reuse an existing microformat or to reuse some purpose built format (like CDWA)? -- [[User:TimG|Tim]]<br />
*** The existence of [[existing-classes]] suggests that we're supposed to reuse existing microformats first, before referring to purpose built formats. -- [[User:TimG|Tim]]<br />
**** That's correct Tim, reuse existing microformats first. This is explained more thoroughly as [http://microformats.org/wiki/naming-principles#Reuse_Microformats_First.2C_Other_Standards_Second part of naming-principles] - Tantek<br />
** Are museums more likely to adopt a standard that is easy to understand and read or one based on an existing standard designed for museums? -- [[User:TimG|Tim]]<br />
*** I think it all depends on the complexity and ease of use. Microformats out-do existing legacy formats (even when based on those legacy formats!) purely because they are simpler to author, and provide a much lower barrier to entry and understanding. - Tantek<br />
** I'm not exactly sure what you mean by extensions. If you mean informal extensions, I think we're better off not sanctioning them. The only fields that are going to be really useful (from a readers/parsers point of view) are the ones that are consistenly applied (the core components you propose). However, if you mean extensions like this microformat is an extension of the [[citation]] microformat (that is, developed using the microformats process), I agree completely. Your thoughts? -- [[User:TimG|Tim]]<br />
<br />
== Proposals ==<br />
<br />
<br />
=== [[citation]] + [http://dublincore.org/documents/dcmi-terms/ Dublin Core] Strawman ===<br />
<br />
* A suggested starting point for the core components of work-of-art. Components are, where possible, either similar to those that are under consideration for inclusion in [[citation]], or part of the Dublin Core. The Getty's [http://www.getty.edu/research/conducting_research/standards/intrometadata/3_crosswalks/crosswalk1.html Metadata Standards Crosswalk] was also taken into consideration. Feedback is welcome. <br />
<br />
* Questions:<br />
** Is some loss of semantic granularity an acceptable trade-off for microformat clarity? (i.e. should we combine components that would be distinct in a CDWA-based schema?)<br />
*** I think the trade off is acceptable. In a nod toward this issue, CDWA makes a distinction between fields intended for indexing (more granular) and fields intended for display (more human friendly). In the CDWA strawman, I opted to use the human friendly/ less granular "display" fields. -- [[User:TimG|Tim]]<br />
** Should creater information rely on an hCard extension for historical figures? It seems as though hCard with the addition of nationality, vital dates, gender, and role have utility in alternative contexts.<br />
*** I think creator information should rely on hCard to the extent that hCard can already handle it. An hCard extension for historical figures would be very useful for us here, but I'd argue it's outside the scope of this microformat. What do you think? -- [[User:TimG|Tim]]<br />
*** We ought to follow the discussion over at [[hresume|hResume]]. Their approach combines [[hCard]] with [[hCalendar]]. With the addition of nationality, vital dates, and gender it would provide a framework for the bio files many museums keep on the artists in their collections. [[hBio]] anyone? -- [[User:TimG|Tim]]<br />
<br />
<br />
{| border="1" cellpadding="3" cellspacing="2"<br />
| '''Component''' || '''Notes''' || '''Approximate CDWA equivalent'''<br />
|-<br />
| title || || [Title or Names]<br />
|- <br />
| creator || (hCard) || [Creation-Creator]<br />
|- <br />
| creator-dates || (dates) || [vitalDatesCreator]<br />
|-<br />
| creator-nationality || || [nationalityCreator]<br />
|-<br />
| creator-role || || [roleCreator]<br />
|-<br />
| subject || (keywords) || [Subject Matter]<br />
|- <br />
| description || || [Descriptive Note]<br />
|- <br />
| date || (date created OR earliest date) || [Creation-Date]<br />
|-<br />
| latest-date || (latest date) || [Creation-Date-Latest Date]<br />
|-<br />
| type || (genre/style) || [Classification] [Styles/Periods] [Object/Work Type]<br />
|- <br />
| format || (dimensions) || [Measurements]<br />
|- <br />
| medium || (media / techniques) || [Materials and Techniques]<br />
|- <br />
| identifier || (repository number / accession number) || [Current Location-Repository Numbers]<br />
|- <br />
| source || (current repository) || [Current Location-Repository Name] <br />
|- <br />
| source-location || (current repository location -- geo?) || [Current Location-Repository Location]<br />
|-<br />
| language || ||<br />
|- <br />
| rights || (copyright information) || [Copyright/Restrictions] <br />
|-<br />
| provenance || || [Ownership/Collecting History-Description]<br />
|-<br />
| series || (connect artworks that are part of a series) || [Related Works]<br />
|}<br />
<br />
[ [http://www.19clicks.com Samantha Orme] ]<br />
<br />
<br />
=== [http://www.getty.edu/research/conducting_research/standards/cdwa/cdwalite/index.html CDWA Lite] Strawman ===<br />
<br />
[http://microformats.org/wiki/class-design-pattern Use class names] based on the [http://www.getty.edu/research/conducting_research/standards/cdwa/cdwalite/index.html CDWA Lite 0.9 Work in Progress XML Schema].<br />
<br />
This example is based on [http://www.getty.edu/research/conducting_research/standards/cdwa/3_cataloging_examples/examples/04_watercolor_turner.html a CDWA example]<br />
<br />
<pre><br />
<nowiki><br />
<span class="cdwalite"><br />
<span class="objectWorkTypeWrap"><br />
<span class="objectWorkType">watercolor</span><br />
</span><br />
<span class="titleWrap"><br />
<span class="titleSet"><br />
<span class="title">Conway Castle, North Wales</span><br />
</span><br />
</span><br />
<span class="displayCreator">Joseph Mallord William Turner (British painter, 1775-1851)</span><br />
<span class="displayMeasurements">53.6 x 76.7 cm (21 1/8 in. x 30 1/8 in.)</span><br />
<span class="displayMaterialsTech">Watercolor and gum arabic with graphite underdrawing</span><br />
<span class="styleWrap"><br />
<span class="style">Romanticism</span><br />
</span><br />
<span class="descriptiveNoteWrap"><br />
<span class="descriptiveNoteSet"><br />
<span class="descriptiveNote">This is the largest of Turner's four extant watercolors of this medieval...</span><br />
</span><br />
</span><br />
<span class="locationWrap"> <br />
<span class="locationSet"><br />
<span class="locationName currentRepository">J. Paul Getty Museum (New York, New York, USA)</span><br />
<span class="locationName repositoryLocation">Los Angeles (California, USA)</span><br />
<span class="locationName repositoryNumbers">95.GC.10.</span><br />
</span><br />
</span> <br />
</span><br />
</nowiki><br />
</pre><br />
<br />
Unresolved issues in CDWA Lite Strawman:<br />
* Is the markup prohibitively complicated?<br />
* Are wrap tags (such as "objectWorkTypeWrap", "titleWrap" etc) necessary?<br />
* Are display tags (such as "displayCreator") preferable to indexing tags? (See the [http://www.getty.edu/research/conducting_research/standards/cdwa/cdwalite/index.html CDWA Lite XML Schema] for a list of display and indexing tags.)<br />
* What is the best way to deal with attributes on xml tags (such as "type=", "termsource=" and "termsourceID=")?</div>RCaninehttps://microformats.org/wiki/index.php?title=User:RCanine&diff=5960User:RCanine2006-04-20T23:24:42Z<p>RCanine: </p>
<hr />
<div>Hi.</div>RCaninehttps://microformats.org/wiki/index.php?title=xfolk-issues&diff=6576xfolk-issues2006-04-20T23:24:13Z<p>RCanine: /* xFolk issues */</p>
<hr />
<div>= xFolk issues =<br />
<br />
These are externally raised issues about [[xfolk|xFolk]] with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec. Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://thecommunityengine.com/home Bud]<br />
<br />
== Template ==<br />
Please use this format:<br />
* YYYY-MM-DD raised by AUTHORNAME<br />
*# ''Issue 1: Here is the first issue I have.''<br />
*# ''Issue 2: Here is the second issue I have.''<br />
<br />
== Issues ==<br />
Please use this format:<br />
* 2006-04-20 raised by [[User:RCanine|Ryan Cannon]]<br />
*# ''Issue 1: As xFolk is intended as a list, it seems tedious to have to place <code>class="xfolkentry"</code> on every element. Are there implementation problems with creating a container class with that implies <code>class="xfolkentry"</code> on every child node?.''</div>RCaninehttps://microformats.org/wiki/index.php?title=citation&diff=4339citation2006-01-02T02:51:50Z<p>RCanine: /* Questions */</p>
<hr />
<div>= Citation Formats =<br />
<br />
== Authors ==<br />
[http://suda.co.uk/ Brian Suda] ; <br />
[http://www.inkdroid.org Ed Summers]<br />
<br />
== Copyright ==<br />
{{MicroFormatCopyrightStatement2004}}<br />
<br />
== Introduction ==<br />
Currently, there has been some discussion about a citation format. This is the wiki page to document current examples of cites/citations on the web today, and current cite/citation formats, and their implicit/explicit schemas, with the intent of deriving a cite microformat from that research.<br />
<br />
== Semantic XHTML Design Principles ==<br />
{{semantic-xhtml-design-principles}}<br />
<br />
== Known Citation Formats ==<br />
This is a list of the known formats for creating citations, this microformat will be a blend of some or all of them. The [[cite-formats|Citation Formats Page]] will be a running tab of these formats.<br />
<br />
Eventually, i would like to see a chart of how each value is represented in each format, and what formats have additional properties that do not map between them. (For example, Format1 calls 'author' 'author', in format2 'author' is called 'writter'. etc)<br />
<br />
== Example Citations ==<br />
[[cite-examples|Citation Examples]] are citations found in the wild that could benefit from semantic mark-up. This is a growing list of examples from all sorts of places including W3C specifications, RFCs and others.<br />
<br />
== Citation Brainstorming Ideas ==<br />
This is the [[cite-brainstorming|brainstorming page]] where just about anything can be put out for discussion.<br />
<br />
== Todo ==<br />
* select a bibliography format to model<br />
* look for HTML tags that give the most semantic meaning<br />
<br />
== Questions ==<br />
* what is the difference between hReview and a Citation format?<br />
** Right a citation is actually very different from a review, and even although a review could be said to contain a citation to the item being reviewed, in practice, the two are very different.<br />
* if a citation is an author or publisher, isn't that just an hCard<br />
* Citations usually contain two parts--a notice that the material is a quoted or paraphrased from a source, and a reference to the location of that source. It seems like we're attempting to do both simultaneously should we make more of an effort to differentiate the two?<br />
<br />
== Modularity ==<br />
My hope for this microformat is that it can be a sort of module that can be used in other microformats. Once this is developed and flushed out, citation references could easily be used for publications on a Resume/CV, therefore the citation microformat would be a module (subset) of all the possible Resume Values.<br />
<br />
Other Microformats that use the Citation Module<br />
* [http://microformats.org/wiki/resume-formats Resume Microformat] (possibly)<br />
<br />
Other Microformats that the Citation Module will use<br />
* [http://microformats.com/wiki/hcard hCard] encodings for things like Author, Publisher (people and companies)<br />
<br />
== References ==<br />
=== Informative References ===<br />
* [http://ocoins.info/ COinS]<br />
* [http://xmlresume.sourceforge.net/ XMLResume]: if part of the drive for citations is for publications for a resume/CV then some of this information could be useful<br />
* [http://www.citeulike.org/ CiteUlike] is a free service to help academics to share, store, and organise the academic papers they are reading<br />
* [http://www.ariadne.ac.uk/issue43/chudnov/ OpenURL] with Autodiscovery<br />
* [http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list "Gather, Create, Share" and "Personal Collection Systems" memes, and systems implementing either or both]<br />
* [http://www.loc.gov/standards/mods/ Metadata Object Description Schema] developed by the Library of Congress<br />
* [http://dublincore.org/ Dublin Core Metadata]<br />
* BibTeX references (I think a citation micro-format would be useful, but BibTeX is not the best model to use. It has a flat metadata model that does a really poor job representing the sort of citations that people outside of the hard sciences cite).<br />
<br />
=== Comments ===<br />
I'm the author of the [http://xbiblio.sourceforge.net/citeproc.html citeproc] project, which includes a micro-format of sorts (though I never thought of it as such) in its XHTML output mode. See [http://xbiblio.sourceforge.net/examples/apa-en.html here] for an example. The difference compared to the bibtex-derived model is that is is a) more generic and b) hierachical. <br />
<br />
It would be possible, certainly, to do a flat model if for some reason there was a good technical reason not to go hierarchical (though is there?), but then you need to think outside the BibTeX box in any case. Any model of this sort ought to be able to handle legal citations, magazine articles, patents, etc. etc.; not just a narrow range of BibTeX types.</div>RCaninehttps://microformats.org/wiki/index.php?title=citation-brainstorming&diff=3615citation-brainstorming2005-12-21T18:59:18Z<p>RCanine: /* Types and Roles */</p>
<hr />
<div>= Citation Brainstroming =<br />
<br />
== XHTML Structure ==<br />
With my exprience working X2V and hCa* has taught me what elememts are easy to find and which are not. Since the Citation microformat is very new it is possible to not make a lot of the same errors twice and to make things easier for extracting application to find and imply certain properties.<br />
<br />
* There should be some sort of 'root node' that implies all child elements are for the Citation microformat.<br />
* Since most people will have multiple Citation there should be away to represent each Citation object as a unqiue block independant of another. This is to keep the parse from finding 'author' and applying to all citations. Each citation should be in a container (class="???") that scoped from others.<br />
<br />
@@ more points will be posted as i remember of them<br />
<br />
== Semantic Meaning ==<br />
One of the guiding priniciple of Microformats is to use the most semantically rich element to describe each node (Point 2 of Semantic XHTML Design Principles: Use the most accurately precise semantic XHTML building block for each object etc). Since we are dealing with HTML and citations, several elements are candidates to be used to enrich the semantic meaning. [http://www.w3.org/TR/REC-html40/struct/text.html CITE, BLOCKQUOTE, Q, A], (are there more?)<br />
<br />
The [[citation-brainstorming|Citation Brainstorming Page]] has a few development and ideas about how to give another person credit for a link. Some of the semantic ideas behind their choices of tags can be applied to a full bibliographic type reference.<br />
<br />
== ISBN:// Protocol ==<br />
[http://www.faqs.org/rfcs/rfc3187.html RFC3187] defines an isbn protocol <br />
<br />
Example:<br />
<br />
URN:ISBN:0-395-36341-1<br />
<br />
I'm not sure if any browser uses this data, but it might be have an application in citations describing registered materials with an ISBN<br />
<br />
<br />
Question: what about using something like OCLC's [http://www.oclc.org/worldcat/open/isbnissnlinking/default.htm WorldCat] for linking titles? - Tim White<br />
<br />
== This and That ==<br />
After reading through alot of different citation encoding formats, i noticed that each format was being used in onw of two ways. It was either to describe the Current page (THIS.PAGE) or being used to encode references that point to external resources (THAT.PAGE)<br />
<br />
The informatation being encoded was identical for both resources (author, date, name, etc) they just reference different things. For this microformat, i'm not sure if we want to try to solve both problems, or just one? The meta tags in the head element would be the ideal place for information about the THIS.PAGE, but that is not in following with the ideals of microformats where information is human-readable. The THAT.PAGE idea where a list of references is at the end of a document in the form of a bibliography is more inline with the ideals of a microformat where the data is human-readable. That doesn't mean that data about the current document shouldn't be human-readable, so some of the same properties used to reference extermal resources can be used for the current document (THIS.PAGE). To do this a different root item could be used and transforming applications could either extract the citation data about the current page, or information about this page's references.<br />
<br />
This is open for discussion, but either way, i believe that the properties used to describe a page will be the same for both THIS and THAT. [http://suda.co.uk/ brian suda]<br />
<br />
== Date Formatting ==<br />
Since microformats are all about re-use and the accepted way to encode Date-Time has been pretty much settled, then this is a good place to start when dealing with all the different date citation types. <br />
<br />
These are all the different fields from various citation formats that are of temporal nature:<br />
* Date (available | created | dateAccepted | dateCopyrighted | dateSubmitted | issued | modified | valid)<br />
* originInfo/dateIssued<br />
* originInfo/dateCreated<br />
* originInfo/dateCaptured<br />
* originInfo/dateOther<br />
* month<br />
* year<br />
* Copyright Year<br />
* Date - Generic<br />
* Date of Confernce<br />
* Date of Publication<br />
* Date of update/revisou/issuance of database record<br />
* Former Date<br />
* Entry Date for Database Record<br />
* Database Update<br />
* Year of Publication<br />
<br />
There are several common properties across several citation domains and will certainly be in the citation microformat, the unique instances will need further consideration, otherwise there could be no end to posiblities. <br />
<br />
There are also several properties (year, month, Year of publication) that can be extracted from another source. Therefore, if you only encode a more specific property such as; Date of Publication, you can extract the 'year of publication' from that. Since the date-time format we are modeling after is the ISO date-time format, just the Year portion is an acceptable date. So if you ONLY know the year of publication, the you can form a valid 'Date of Publication' as a microformat (which inturn is a valid 'year of publication') - you milage may vary when it comes to importing into citation applications.<br />
<br />
== Types and Roles ==<br />
There are many different types of publications and this information should be captured in the citation. Possible types include:<br />
* Novel/fiction (specify type -- literature, sci-fi, romance, etc.?)<br />
* Non-fiction<br />
* Poem<br />
* Play<br />
* Magazine<br />
* Reference (seperate out encyclopedia, dictionary, almanac, etc.?)<br />
* Journal<br />
* Article within a journal<br />
* Chapter within a book<br />
* Dissertation<br />
* Web Site<br />
* Page within a web site<br />
* Music Recording<br />
* Video Recording<br />
* Interview<br />
* Physical object (Statue, Painting, etc.)<br />
* ??<br />
<br />
Question: <br />
Certain works have specific types of citations, for example, the Bible--and, I assume, other religious works--have very specific citation formats with different relevant information (chapter/verse) than others, as do the works of Shakespeare. Should these be considered seperate types/roles?<br />
<br />
Likewise, there are several different roles associated with publications -- author, co-author, editor, translator, etc. Should these be captured under a master "role" or treated as individual elements?<br />
<br />
== Tags ==<br />
Some of the citation formats has a place for 'keywords' or 'generic tags', etc. This might be a good place to re-use the [http://microformats.org/wiki/rel-tag RelTag microformat]. The downside would be that they are then forced to be links, which might be the correct way to mark-up these terms.<br />
<br />
<br />
== OpenURL ==<br />
<br />
<br />
OpenURL is in use in library software around the world to allow citation metadata to be embedded in URLs. Typically these URLs are used for targeting resolvers which essentially proxy access to licensed content. OpenURL also provides an XML encoding. The [http://alcme.oclc.org/openurl/servlet/OAIHandler?verb=ListRecords&metadataPrefix=oai_dc&set=Core:Metadata+Formats key/value] pairs used in OpenURL could relatively easily be adapted to semantic HTML. This is a cow path that could be paved relatively easily using existing modules as appropriate.<br />
<br />
OpenURL has a microformat-like encoding: [http://ocoins.info/ COinS]. This uses the 'title' attribute of HTML 'span' tags to embed OpenURL URLs.<br />
<br />
Example (from a book review written using the Structured Blogging plugin):<br />
<br />
<pre><nowiki><br />
<p><b>ISBN</b>: <span class='Z3988'<br />
title='ctx_ver=Z39.88-2004&amp;amp;rft_val_fmt=info:ofi/fmt:kev:mtx:book&amp;amp;rft.isbn=0679426612'><br />
0679426612</span></p><br />
</nowiki></pre><br />
<br />
== MARC / MODS / Dublin Core ==<br />
<br />
The MODS ([http://www.loc.gov/standards/marcxml/Sandburg/sandburgmods.xml example]) and Dublin Core ([http://www.loc.gov/standards/marcxml/Sandburg/sandburgdc.xml example]) transformations of MARC21 may contain some useful ideas.<br />
<br />
Here's a first attempt at rewriting the linked examples in XHTML (written in response to a [http://microformats.org/discuss/mail/microformats-discuss/2005-December/002438.html mailing list query about encoding book information with microformats]):<br />
<br />
<pre><nowiki><br />
<div class="book" lang="en"><br />
<h3 class="fn">Arithmetic /</h3><br />
<p>By <span class="creator"><span class="fn">Sandburg, Carl</span>,<br />
<span class="date">1878-1967</span></span>,<br />
and <span class="illustrator">Rand, Ted</span></p><br />
<p>Publisher: <span class="publisher"><span class="fn">Harcourt Brace Jovanovich</span>,<br />
<span class="locality">San Diego</span></span></p><br />
<p>Published: <span class="issued">1993</span></p><br />
<p class="description">A poem about numbers and their characteristics. Features<br />
anamorphic, or distorted, drawings which can be restored to normal by viewing<br />
from a particular angle or by viewing the image's reflection in the provided<br />
Mylar cone.</p><br />
<p class="note">One Mylar sheet included in pocket.</p><br />
<p>Subjects:</p><br />
<ul><br />
<li class="subject">Arithmetic</li><br />
<li class="subject">Children's poetry, American.</li><br />
<li class="subject">Arithmetic</li><br />
<li class="subject">American poetry</li><br />
<li class="subject">Visual perception</li><br />
</ul><br />
</div><br />
</nowiki></pre><br />
<br />
Here is [http://www.aadl.org/cat/seek/search/X?SEARCH=knitting&searchscope=26&x=0&y=0&SORT=D&sourceid=Mozilla-search&rss=1 an example of the HTML (inside an RSS feed)] that the [http://www.aadl.org Ann Arbor District Library ] is generating and wants to mark up with some sort of publication microformat.</div>RCaninehttps://microformats.org/wiki/index.php?title=citation-brainstorming&diff=3500citation-brainstorming2005-12-21T17:13:11Z<p>RCanine: /* Types and Roles */</p>
<hr />
<div>= Citation Brainstroming =<br />
<br />
== XHTML Structure ==<br />
With my exprience working X2V and hCa* has taught me what elememts are easy to find and which are not. Since the Citation microformat is very new it is possible to not make a lot of the same errors twice and to make things easier for extracting application to find and imply certain properties.<br />
<br />
* There should be some sort of 'root node' that implies all child elements are for the Citation microformat.<br />
* Since most people will have multiple Citation there should be away to represent each Citation object as a unqiue block independant of another. This is to keep the parse from finding 'author' and applying to all citations. Each citation should be in a container (class="???") that scoped from others.<br />
<br />
@@ more points will be posted as i remember of them<br />
<br />
== Semantic Meaning ==<br />
One of the guiding priniciple of Microformats is to use the most semantically rich element to describe each node (Point 2 of Semantic XHTML Design Principles: Use the most accurately precise semantic XHTML building block for each object etc). Since we are dealing with HTML and citations, several elements are candidates to be used to enrich the semantic meaning. [http://www.w3.org/TR/REC-html40/struct/text.html CITE, BLOCKQUOTE, Q, A], (are there more?)<br />
<br />
The [[citation-brainstorming|Citation Brainstorming Page]] has a few development and ideas about how to give another person credit for a link. Some of the semantic ideas behind their choices of tags can be applied to a full bibliographic type reference.<br />
<br />
== ISBN:// Protocol ==<br />
[http://www.faqs.org/rfcs/rfc3187.html RFC3187] defines an isbn protocol <br />
<br />
Example:<br />
<br />
URN:ISBN:0-395-36341-1<br />
<br />
I'm not sure if any browser uses this data, but it might be have an application in citations describing registered materials with an ISBN<br />
<br />
<br />
Question: what about using something like OCLC's [http://www.oclc.org/worldcat/open/isbnissnlinking/default.htm WorldCat] for linking titles? - Tim White<br />
<br />
== This and That ==<br />
After reading through alot of different citation encoding formats, i noticed that each format was being used in onw of two ways. It was either to describe the Current page (THIS.PAGE) or being used to encode references that point to external resources (THAT.PAGE)<br />
<br />
The informatation being encoded was identical for both resources (author, date, name, etc) they just reference different things. For this microformat, i'm not sure if we want to try to solve both problems, or just one? The meta tags in the head element would be the ideal place for information about the THIS.PAGE, but that is not in following with the ideals of microformats where information is human-readable. The THAT.PAGE idea where a list of references is at the end of a document in the form of a bibliography is more inline with the ideals of a microformat where the data is human-readable. That doesn't mean that data about the current document shouldn't be human-readable, so some of the same properties used to reference extermal resources can be used for the current document (THIS.PAGE). To do this a different root item could be used and transforming applications could either extract the citation data about the current page, or information about this page's references.<br />
<br />
This is open for discussion, but either way, i believe that the properties used to describe a page will be the same for both THIS and THAT. [http://suda.co.uk/ brian suda]<br />
<br />
== Date Formatting ==<br />
Since microformats are all about re-use and the accepted way to encode Date-Time has been pretty much settled, then this is a good place to start when dealing with all the different date citation types. <br />
<br />
These are all the different fields from various citation formats that are of temporal nature:<br />
* Date (available | created | dateAccepted | dateCopyrighted | dateSubmitted | issued | modified | valid)<br />
* originInfo/dateIssued<br />
* originInfo/dateCreated<br />
* originInfo/dateCaptured<br />
* originInfo/dateOther<br />
* month<br />
* year<br />
* Copyright Year<br />
* Date - Generic<br />
* Date of Confernce<br />
* Date of Publication<br />
* Date of update/revisou/issuance of database record<br />
* Former Date<br />
* Entry Date for Database Record<br />
* Database Update<br />
* Year of Publication<br />
<br />
There are several common properties across several citation domains and will certainly be in the citation microformat, the unique instances will need further consideration, otherwise there could be no end to posiblities. <br />
<br />
There are also several properties (year, month, Year of publication) that can be extracted from another source. Therefore, if you only encode a more specific property such as; Date of Publication, you can extract the 'year of publication' from that. Since the date-time format we are modeling after is the ISO date-time format, just the Year portion is an acceptable date. So if you ONLY know the year of publication, the you can form a valid 'Date of Publication' as a microformat (which inturn is a valid 'year of publication') - you milage may vary when it comes to importing into citation applications.<br />
<br />
== Types and Roles ==<br />
There are many different types of publications and this information should be captured in the citation. Possible types include:<br />
* Novel/fiction (specify type -- literature, sci-fi, romance, etc.?)<br />
* Non-fiction<br />
* Poem<br />
* Play<br />
* Magazine<br />
* Reference (seperate out encyclopedia, dictionary, almanac, etc.?)<br />
* Journal<br />
* Article within a journal<br />
* Chapter within a book<br />
* Dissertation<br />
* Web Site<br />
* Page within a web site<br />
* Music Recording<br />
* Video Recording<br />
* Interview<br />
* Physical object (Statue, Painting, etc.)<br />
* ??<br />
<br />
Question: <br />
Certain works have specific types of citations, for example, the Bible--and, I assume, other religious works--have very specific citation formations with different relevant information (chapter/verse) than others, as do the works of Shakespeare. Should these be considered seperate types/roles?<br />
<br />
Likewise, there are several different roles associated with publications -- author, co-author, editor, translator, etc. Should these be captured under a master "role" or treated as individual elements?<br />
<br />
== Tags ==<br />
Some of the citation formats has a place for 'keywords' or 'generic tags', etc. This might be a good place to re-use the [http://microformats.org/wiki/rel-tag RelTag microformat]. The downside would be that they are then forced to be links, which might be the correct way to mark-up these terms.<br />
<br />
<br />
== OpenURL ==<br />
<br />
<br />
OpenURL is in use in library software around the world to allow citation metadata to be embedded in URLs. Typically these URLs are used for targeting resolvers which essentially proxy access to licensed content. OpenURL also provides an XML encoding. The [http://alcme.oclc.org/openurl/servlet/OAIHandler?verb=ListRecords&metadataPrefix=oai_dc&set=Core:Metadata+Formats key/value] pairs used in OpenURL could relatively easily be adapted to semantic HTML. This is a cow path that could be paved relatively easily using existing modules as appropriate.<br />
<br />
OpenURL has a microformat-like encoding: [http://ocoins.info/ COinS]. This uses the 'title' attribute of HTML 'span' tags to embed OpenURL URLs.<br />
<br />
Example (from a book review written using the Structured Blogging plugin):<br />
<br />
<pre><nowiki><br />
<p><b>ISBN</b>: <span class='Z3988'<br />
title='ctx_ver=Z39.88-2004&amp;amp;rft_val_fmt=info:ofi/fmt:kev:mtx:book&amp;amp;rft.isbn=0679426612'><br />
0679426612</span></p><br />
</nowiki></pre><br />
<br />
== MARC / MODS / Dublin Core ==<br />
<br />
The MODS ([http://www.loc.gov/standards/marcxml/Sandburg/sandburgmods.xml example]) and Dublin Core ([http://www.loc.gov/standards/marcxml/Sandburg/sandburgdc.xml example]) transformations of MARC21 may contain some useful ideas.<br />
<br />
Here's a first attempt at rewriting the linked examples in XHTML (written in response to a [http://microformats.org/discuss/mail/microformats-discuss/2005-December/002438.html mailing list query about encoding book information with microformats]):<br />
<br />
<pre><nowiki><br />
<div class="book" lang="en"><br />
<h3 class="fn">Arithmetic /</h3><br />
<p>By <span class="creator"><span class="fn">Sandburg, Carl</span>,<br />
<span class="date">1878-1967</span></span>,<br />
and <span class="illustrator">Rand, Ted</span></p><br />
<p>Publisher: <span class="publisher"><span class="fn">Harcourt Brace Jovanovich</span>,<br />
<span class="locality">San Diego</span></span></p><br />
<p>Published: <span class="issued">1993</span></p><br />
<p class="description">A poem about numbers and their characteristics. Features<br />
anamorphic, or distorted, drawings which can be restored to normal by viewing<br />
from a particular angle or by viewing the image's reflection in the provided<br />
Mylar cone.</p><br />
<p class="note">One Mylar sheet included in pocket.</p><br />
<p>Subjects:</p><br />
<ul><br />
<li class="subject">Arithmetic</li><br />
<li class="subject">Children's poetry, American.</li><br />
<li class="subject">Arithmetic</li><br />
<li class="subject">American poetry</li><br />
<li class="subject">Visual perception</li><br />
</ul><br />
</div><br />
</nowiki></pre><br />
<br />
Here is [http://www.aadl.org/cat/seek/search/X?SEARCH=knitting&searchscope=26&x=0&y=0&SORT=D&sourceid=Mozilla-search&rss=1 an example of the HTML (inside an RSS feed)] that the [http://www.aadl.org Ann Arbor District Library ] is generating and wants to mark up with some sort of publication microformat.</div>RCanine