Re: [uf-discuss] [citation] citation root element
In message [EMAIL PROTECTED], Michael McCracken [EMAIL PROTECTED] writes are the people who are voting for hCite intending the capital C? Not me: hCite = uF name hcite = root class name I concur with Andy. I was refereeing to hCite as the name. Seems we are reaching consensus on hcite as the root. +1 hcite However, I still have my original question -- at one point there were cite and citation explorations going on. I believe the cite was related to blog posting (citing one post in another). Has this been renamed? ~ Tim a href=http://www.tjameswhite.com;tjameswhite.com/a TV dinner still cooling? Check out Tonight's Picks on Yahoo! TV. http://tv.yahoo.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [citation] citation root element
In message [EMAIL PROTECTED], Michael McCracken [EMAIL PROTECTED] writes are the people who are voting for hCite intending the capital C? Not me: hCite = uF name hcite = root class name -- Andy Mabbett http://www.pigsonthewing.org.uk/uFsig/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [citation] citation root element
In message [EMAIL PROTECTED], Tim White [EMAIL PROTECTED] writes How about hCitation then? Like the others mention, you know its a format for citations. I could live with hCite as well... hCite says as much as hCitation, in fewer characters. hCite +1 hCitation0 hBib-1 -- Andy Mabbett http://www.pigsonthewing.org.uk/uFsig/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [citation] citation root element
On 1/12/07, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Tim White [EMAIL PROTECTED] writes How about hCitation then? Like the others mention, you know its a format for citations. I could live with hCite as well... hCite says as much as hCitation, in fewer characters. hCite +1 hCitation0 hBib-1 Noting the points about case sensitivity in hCard-parsing [1] that Tantek referred to - are the people who are voting for hCite intending the capital C? I prefer the hcite capitalization. After reading Tantek's points, I vote: -1 'citation' -1 'hbib' -1 'hcitation' +1 'hcite' cheers, -mike [1]: http://microformats.org/wiki/hcard-parsing#root_class_name PS, why the 'h' - is it an upside-down µ, or does it stand for 'html'? -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] [hCite] title
In Brian's book example on the citation-brainstorming wiki page, the title of the book is marked up with class=fn. Every example we have uses 'title', except for the US. patent. I vote to change that example to use 'title' and verify that 'title' is the class name to be used to represent titles of hCite elements. Other votes? (Note: some formats use a different field name for titles that are chapter titles. Recall that for hCite we have the 'container' field, which is a nested hCite and would store the title of the containing book as its own 'title'.) -mike -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [citation] citation root element
On 1/13/07, Tim White [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Michael McCracken [EMAIL PROTECTED] writes are the people who are voting for hCite intending the capital C? Not me: hCite = uF name hcite = root class name I concur with Andy. I was refereeing to hCite as the name. Seems we are reaching consensus on hcite as the root. +1 hcite I agree that this seems like a consensus on 'hcite' as the root class name. I have updated the examples on citation-brainstorming to reflect this, and added a note to the working straw schema. There is a note about using cite as the recommended root element - I don't feel strongly about this - does anyone else? I suppose a final standard should have a note to suggest using cite when appropriate, but I'm not concerned about it now. However, I still have my original question -- at one point there were cite and citation explorations going on. I believe the cite was related to blog posting (citing one post in another). Has this been renamed? I, for one, don't know. -mike -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [citation]: Brian's outstanding issues 3: nesting
Just about this part: I have no opinion about citation vs. hcite. -mike http://microformats.org/wiki/naming-principles#h_word That page suggests that hcite for the root element is the way to go. -mike -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [citation] citation root element
On 1/11/07, Tantek Çelik [EMAIL PROTECTED] wrote: + 1 for citation -1 for citation, it is too generic for a root class name. Makes sense; I'll withdraw any vote for `citation`. The pedant in me says that cite is a verb and not really appropriate to label something that is a noun. The poet in me likes the way hcite rolls off of the tongue. hbib offends both sensibilities. + 1 hcite - 1 hcitation - 1 hbib -- Ryan Cannon Interactive Developer MSI Student, School of Information University of Michigan http://RyanCannon.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [hcite] nesting container elements
On Mar 29, 2007, at 2:41 PM, Michael McCracken wrote: I propose a 'container' class name that would be attached to a nested hCite instance to note when the nested hCite represents the containing item for the root hCite. The journal example above would then look something like this: span class=hcite span class=titleDifferent base/base mismatches are corrected with different efficiencies by the methyl-directed DNA mismatch- repair system of E. coli /span ... span class=hcite container span class=titleCell/span ... /span /span Comments? Maybe this has already been covered and I missed it, but why wouldn't we use HTML nesting to indicate citation nesting? That is, rather than specify which node is a container with a class name, do it by actually having it contain the relevant nodes, e.g. (and I'm proposing this as actual markup, just how nesting could work): div class=hcite journal div class=hcite article h3 class=titleDifferent base/base mismatches are corrected with different efficiencies by the methyl-directed DNA mismatch- repair system of E. coli/h3 /div ... h2 class=titleCell/h2 /div That would require parsers to know all potential sub-types of each media type so an article title wouldn't get misinterpreted as a journal title, but that looks to me like a relatively small burden for parsers in exchange for simpler publishing. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] [citation] citation root element
From Ryan Cannon on Dec 18th on the wiki: 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. I agree, 'citation' is clearer - can we vote on this? If we get a quorum, I'll edit the wiki examples to reflect the decision. -mike -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] [hCite] call for examples: language
I'd like to hear some discussion on the language field for hCite. I think it is useful, but it has two things going against it for me: - many citation formats have supported useful work without storing the language (I've never had 'language' in a bibtex entry, nor seen it written in a list of references - even when it is obviously not the same language as the referring page/paper.) - We only have two examples of pages marking up the language on the web - W3C and Amazon.com. The second point is why I'm writing this - I am happy to admit that it's useful to be able to mark up the language, and I'd have no problem with 'language' as an optional field in hCite, but if there are no other examples to be found, that suggests to me that maybe it's not really necessary. I'm open to the thought that Amazon alone is enough examples, because of its size, but I'm not totally sold on that. So - if you feel that hCite needs a language field, please find relevant examples from the web and add them to the wiki, then point to them in this thread. -mike -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
On Nov 13, 2006, at 4:58 PM, Andy Mabbett wrote: I agree. It doesn't seem to help any of the use cases identified in the wiki: http://microformats.org/wiki/citation-brainstorming#Use_Cases It does: http://microformats.org/wiki/citation- brainstorming#Buy_a_copy Both Amazon and ABE cite page counts. Sure, but neither allow searching for books by those page counts that I see, so this doesn't seem to help with the stated task: Find the cited work on, for example, Amazon or ABE. Page count still looks out of scope to me for hCite, and closer to the type of information (i.e. file size) being discussed in media-info. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [citation] citation root element
Tantek said: -1 for citation, it is too generic for a root class name. If you look at other established / adopted microformats, you'll see that they have fairly unique-ish root class names as well. hCalendar - vevent, vcalendar (taken from RFC2445) hReview - hreview (by pattern extension) xFolk - xfolkentry (I would have picked just 'xfolk' today, not sure why we went with xfolkentry) hListing proposal - hlisting Thus here is another suggestion, based on what I remember of Rohit's idea, for the root class name for the citation microformat: hcite Thanks, Tantek How about hCitation then? Like the others mention, you know its a format for citations. I could live with hCite as well... ... though if I recall, at one point there was some hCite work going on which was different from the citation efforts. The two were intermingled until Ryan (I believe) sorted out the wiki pages giving us the current citation discussion pages. Has that been merged/renamed? +1 hCitation 0/+1 hCite -1 hBib ~Tim Need a quick answer? Get one in minutes from people who know. Ask your question on www.Answers.yahoo.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [hCite] call for examples: language
On 1/31/07, Brian Suda [EMAIL PROTECTED] wrote: On 1/31/07, Michael McCracken [EMAIL PROTECTED] wrote: I'd like to hear some discussion on the language field for hCite. I think it is useful, but it has two things going against it for me: - many citation formats have supported useful work without storing the language (I've never had 'language' in a bibtex entry, nor seen it written in a list of references - even when it is obviously not the same language as the referring page/paper.) - We only have two examples of pages marking up the language on the web - W3C and Amazon.com. The second point is why I'm writing this - I am happy to admit that it's useful to be able to mark up the language, and I'd have no problem with 'language' as an optional field in hCite, but if there are no other examples to be found, that suggests to me that maybe it's not really necessary. I'm open to the thought that Amazon alone is enough examples, because of its size, but I'm not totally sold on that. So - if you feel that hCite needs a language field, please find relevant examples from the web and add them to the wiki, then point to them in this thread. --- HTML gives us a mechanism for determining the language. the @lang attribute or @xml:lang. Both of these are in use already with hCard and hCalendar. It would make sense to simply extend them to hCite as well. If we use @lang, doesn't that mean we're specifying the language of the words in the hCite element, but not necessarily the language of the thing we're citing? -mike -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] hCite needs an evangelist
hCite has shown up in the list a bit recently, but no actual work is being done. The citation wiki pages haven't changed much since April. At this point, it seems like all it serves to do in reality is discourage people from developing more focused microformats for subsets of what hCite should support. Please, let's fix that. There are several open issues, explained neatly on the wiki at /citation-issues, and now we need someone to gather interested parties and sort those issues out. I wanted to do that, but I will not be able to. I am sending this in case one of you might consider doing this, but thought that someone else was already on it. As far as I can tell, no one is, but if you'd like to start, there are probably lots of people who would be glad to see it moving again. I sure would. Best of luck, -mike -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
On Nov 14, 2006, at 7:59 PM, Scott Reynen wrote: Does the it's to which you're referring, Scott, mean hCite for a reviewed book in general, or marking up page numbers specifically? Neither. I was referring only to page count (which is different than page numbers). Good catch; I meant page count, but didn't actually type that, there and a few other places in my email. My bad. Yes. Nearly every type of microformat published in the wild contains content that isn't part of the microformat's purpose. Parsers just ignore this unrelated content. But it can still be intermingled in the HTML. Awesome, thanks! My understanding of why page counts exist in book review bibliographic information is that it is a legacy from older problems with knowing which book is the right book, or the book your referring to; I might refer to a version that has, say, 438 pages, but there might be another print run that had, for various reasons, 420 pages. This is so much a problem anymore, so maybe it isn't a problem for hCite. If that were a common problem I think it would be a compelling reason to include page counts. But if it's just an edge case, hCite can still be useful to the 80% (or more) cases where page count is irrelevant, and people can still read the page count where it's relevant even if machines can't. This makes sense. I don't think it is anymore, especially with the prominence of editions and versions of printed works. From my understanding, keeping page counts has been simply a legacy of that problem. It might also serve a purpose for book stores trying to determine how much shelf space they need for certain books, but this is merely speculation on my part. In any case, neither is really a good argument for including page counts in hCite. Is there a reason why hCite could not be used in a book review marked up in hReview? I don't see any. You have to cite a book before you can review it, right? Quite true; you do have to include the bibliographic information before you can review it, at least in a standard academic review. I guess, then, that we should at some point add hCitation to the review wiki page. I do think that, if we decide that this is out of the scope of hCite, it would be good to include on the wiki somewhere some explanation of why certain bibliographic/citation elements are left out of hCite. Especially for folks who regularly write out references and citations and are just picking up on microformats; folks like me:) Best, Jeremy ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite nesting (citation/bibliography/collection/collections)
Jeff McNeill wrote: Question: is there a set of semantic containers that could identify a bibliography within a given document, as well as a collection of bibliographies across documents? What's wrong with... ul class=bibliography/a link href=foobar rel=bibliography (from each document in the collection) -- Benjamin Hawkes-Lewis ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
On 11/13/06, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Bruce D'Arcus [EMAIL PROTECTED] writes But citation uFs are being recommended for more than pure academic citations - in resumes, for example, where the page count is likely to be far more relevant. I seriously doubt it. That's your prerogative; but foolish. Particularly as it was mentioned just today: http://microformats.org/discuss/mail/microformats-discuss/2006-November/007103.html I fully accept the argument that hCite might be used for resumes. But that message from Ryan says nothing about page count. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [hcite] date-published
Jeremy said: Though not really arguing against Tim's reasons, there are cases in which citations can have a date published and a date visited or accessed. Most definitely. I did not mean to discount the value of date-accessed. That said, should there also be a date-accessed or date-visited value for hCite? I believe date-access is in the staw schema... yup, it's there. http://microformats.org/wiki/citation-brainstorming#Basic_Citation_Stuctures ~ Tim tjameswhite.com'http://www.tjameswhite.com;tjameswhite.com Looking for earth-friendly autos? Browse Top Cars by Green Rating at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
I’ve been working on my resume this weekend, and have been slopping together an hCite-ish beast for my publications. One thing about type: I don't think this should be—or at least should have to be—visible data. In most use cases that I can think of: a blogger linking to another blog, a list of citations at the end of a scholarly article, citation-hunting through a database, etc. The difference between “article,” “book,” “incollection” and “conference” are either not relevant or are implied by the types of data that the citation contains. I’d much prefer to see: cite class=article citation.../cite Than cite class=citationspan class=typeArticle/span: .../ cite I’ll check over the wiki and make sure my citations match the proposal, and be sure to post problems questions. -- Ryan http://RyanCannon.com On Nov 13, 2006, at 11:40 AM, microformats-discuss- [EMAIL PROTECTED] wrote: Date: Mon, 13 Nov 2006 16:39:44 + From: Brian Suda [EMAIL PROTECTED] Subject: [uf-discuss] hCite progress ... 2) one of the manditory properties across several different citation formats is TYPE. Is this a Book, Journal entry, Thesis, Video, etc. Usually and enumerated list of values. The issue is that EVERYONE does it differently... so should hCite have an enumerated list of types such as Thesis and that maps to bibTeX mastersthesis and RIS THES or should that be something transforming apps handle. I'm not sure how to handle this (i'd prefer not to use enumerated lists of possible values) but if we allow open values, and i write span class=typeThesis/span and that gets converted to a citation format, it will fail most of the formats because the string Thesis is not a valid type. I also think it is silly then to do span class=typeTHES/span and then be valid for only one format. This is where a hard-coded list of values in hCite would help, hCite's thesis can be interpreted into various formats' TYPE values - although i don't like that idea, but don't have any other suggestions except to ignore it and let the implementor figure it out? Any comments? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
In message [EMAIL PROTECTED], Scott Reynen [EMAIL PROTECTED] writes But I do feel strongly that page count is beyond scope. I agree. It doesn't seem to help any of the use cases identified in the wiki: http://microformats.org/wiki/citation-brainstorming#Use_Cases It does: http://microformats.org/wiki/citation-brainstorming#Buy_a_copy Both Amazon and ABE cite page counts. -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] hCite problem statement/purpose of hCite?
This question stems from reading the hCite progress thread[1]: In reading the available citation pages on the wiki[2], the problems that hCitation tries to solve aren't stated anywhere clearly on the wiki, per the process.[3] (If I've missed it by mistake, I apologize.) Is there a page that has hCite's problem statement? I understand from a previous thread[4] that Tim White raised this question in January, 2006, but I'm not clear from the thread if his question was really answered. I'm not concerned so much whether the process was followed, but I'm still wondering, at this point, if we have or are in the process of creating a problem statement for hCitation. Problem statements seem pretty handy, especially for folks who don't understand the scope or purpose of a specific microformat. I only ask because I'm confused about the specific purposes of hCitation, and the problems it tries to solve. Does it involve only instances in which one is citing a work as an authority, or acknowledge the source for a quote or idea? Or is it for marking up general bibliographic information? Or both, and other contexts? There are significant semantic differences between a citation and a simple bibliographic listing. In other words, its one thing for me to quote and cite a passage from Jeremy Keith's _DOM Scripting_, but a different thing to simply list Keith's book in a bibliography along with other books on JavaScript. There are also differences in listing one's own work in a CV, and printing bibliographic information in a review. A few others have already pointed these differences out in past discussions.[5] I'm just wondering that, if the number of pages in a book is out of the scope of hCite, why is it out of the scope, what else is out of the scope, and what would be in the scope? Thanks, Jeremy [1] http://microformats.org/discuss/mail/microformats-discuss/2006- November/thread.html#7102 [2] http://microformats.org/wiki/citation-faq http://microformats.org/wiki/citation-examples http://microformats.org/wiki/citation-examples-markup http://microformats.org/wiki/citation-brainstorming http://microformats.org/wiki/citation-formats http://microformats.org/wiki/citation [3] http://microformats.org/wiki/process [4] http://microformats.org/discuss/mail/microformats-discuss/2006- January/thread.html#2837 [5] http://microformats.org/discuss/mail/microformats-discuss/2005- August/000646.html ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [citation] citation root element
Tantek, microformat back in 2005 May at the WWW2005 conference in Tokyo, he used hBib or hCite (I don't quite remember, perhaps Rohit will see this and speak up) as a candidate name for the microformat it was hBib IIRC john John Allsopp style master :: css editor :: http://westciv.com/style_master blog :: dog or higher :: http://blogs.westciv.com/dog_or_higher Web Directions North, Vancouver Feb 6-10 :: http:// north.webdirections.org ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation: next steps?
On Aug 30, 2006, at 12:42 PM, Michael McCracken wrote: I'm not convinced that a formalized Dublin Core microformat class set is necessary for a good citation microformat, and I do think it'd be a distraction to getting the main goal completed. A modular system with hDC broken out does seem a little complex. I'm happy to borrow from hCite, and I'd hope that hCite would be designed to have pieces reused. I say that because I'm interested in using hCite to describe works of art. From my point of view, class names based on DC's very general terms seem like a good choice, class names based on a medium specific citation format like BibTeX seem less good. For example, BibTeX's author field implies the medium of the cited work (if it has an author, it must be text). This makes it difficult to reuse terminology: what if I'm talking about something that had a painter, not an author? Using a more general term, like DC's creator get's the same work done, and is more easily reused: it can be applied to text, paintings, websites, and so on. It would be great, then, if hCite were to be a superset of DC, using more medium specific terms from something like BibTeX only when no adequate alternative existed in DC. This way we sidestep the distraction of creating a DC format, but get the benefit of generic terms in the larger microformats class name pool. Thanks, Tim ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
hCite Transformations Test (was Re: [uf-discuss] hCite progress)
On Nov 13, 2006, at 11:39 AM, Brian Suda wrote: This is the new home for all the citation transformations: http://suda.co.uk/projects/microformats/hcite/ Thanks Brian. I've marked up some book examples at: http://clioweb.org/hcitations.php For some reason, when I do a transformation, I get the author name for both TITLE and AUTHOR when I put the author first in the markup, like so: div class=hcite book span class=author vcard span class=fnRoy Rosenzweig/span /span, span class=fnThe Park and the People: A History of Central Park/span. span class=publisher vcard span class=localityIthaca/span, abbr title=New York class=regionNY/abbr: span class=fnCornell University Press/span /span, 1998. /div The parser associated the correct TITLE and AUTHOR, however, if I put the publication's title first, then the author name: div class=hcite book span class=fnThe Park and the People: A History of Central Park/span. span class=author vcard span class=fnRoy Rosenzweig/span /span. span class=publisher vcard span class=localityIthaca/span, abbr title=New York class=regionNY/abbr: span class=fnCornell University Press/span /span, 1998. /div I'm assuming this has something to do with the multiple FNs. It gets the publisher's name OK too, but not the publisher location. I may have these coded incorrectly, but will be glad to make any corrections. I also plan to put up more examples of other types of publications, if that is helpful. Best, Jeremy ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [hCite] call for examples: language
On 1/31/07, Michael McCracken [EMAIL PROTECTED] wrote: I'd like to hear some discussion on the language field for hCite. I think it is useful, but it has two things going against it for me: - many citation formats have supported useful work without storing the language (I've never had 'language' in a bibtex entry, nor seen it written in a list of references - even when it is obviously not the same language as the referring page/paper.) - We only have two examples of pages marking up the language on the web - W3C and Amazon.com. The second point is why I'm writing this - I am happy to admit that it's useful to be able to mark up the language, and I'd have no problem with 'language' as an optional field in hCite, but if there are no other examples to be found, that suggests to me that maybe it's not really necessary. I'm open to the thought that Amazon alone is enough examples, because of its size, but I'm not totally sold on that. So - if you feel that hCite needs a language field, please find relevant examples from the web and add them to the wiki, then point to them in this thread. --- HTML gives us a mechanism for determining the language. the @lang attribute or @xml:lang. Both of these are in use already with hCard and hCalendar. It would make sense to simply extend them to hCite as well. -brian -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] hCite elevator pitch and my bibliography generator
I needed a .bib-based bibliography generator for XHTML, so I wrote one with help from a friend who had developed a .bib parser. The output of my generator can be seen at http://hsivonen.iki.fi/thesis/html5-conformance-checker.xhtml#references I've wrapped the values of .bib fields in elements whose class name is the .bib field name. I did it just in case. I don't have any consumer use case for those class names. It was just super-easy to generate them. My use case (publishing an academic paper with a bibliography) is not mentioned as a use case at http://microformats.org/wiki/citation-brainstorming . More to the point, the wiki has no consumer use case for my publication use case. Does this mean that hCite is not for me at all? If hCite is for me, what's the elevator pitch convincing me to put more effort into my generator? What benefits should I expect if I do? Is hCite mature enough to be implemented yet? Moreover, is it even possible to generate hCite from my source data (http://hsivonen.iki.fi/thesis/dippa.bib) without sacrificing the presentation that I want and without potentially generating bogus markup for personal names? For example, my source data does not encode explicitly the given name, the family name and other stuff that isn't quite neither. As far as I can tell, it is impossible to tell heuristically that the middle token in these two names is semantically different: Gavin Thomas Nicol Henrik Frystyk Nielsen -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: [hcite] nesting container elements
I've added an example for a journal article to the wiki:
http://microformats.org/wiki/citation-brainstorming#Citing_a_journal_article
-mike
2007/3/29, Michael McCracken [EMAIL PROTECTED]:
(note - I originally sent this to uf-dev accidentally. My impression
is that more hcite people are on uf-discuss. Correct me if I'm wrong
and we can move this to uf-dev. Thanks!)
We need to deal with bibliographic details for things like chapters in
a book, articles in a journal or magazine, and issues in a series.
For designing a format, the main problem is that there are duplicate
items that need to be scoped - for instance, both the article and the
journal have a title.
The point has been made in a few places that many existing
bibliographic formats handle this by just adding fields at the top
level - for example in the common usage of bibtex, a chapter of a book
is a record of type inbook, and the title field represents the
book title, while the chapter title is recorded in the chapter
field. For example:
@inbook{TAOCP4b,
title = {The Art of Computer Programming: Graph and Network Algorithms},
chapter = {Expander Graphs},
...
}
While it's certainly possible to continue this scheme of adding field
names whenever a publication type can be contained by another type
with clashing fields, other formats have adopted an approach that
avoids this field name multiplication, at the cost of a little extra
complexity in nesting. For example, an article in a journal,
represented in MODS XML (from
http://www.scripps.edu/~cdputnam/software/bibutils/mods_intro.html ):
mods ID=C003
titleInfo
titleDifferent base/base mismatches are corrected with
different efficiencies by the methyl-directed DNA mismatch-repair
system of E. coli/title
/titleInfo
...
relatedItem type=host
titleInfo
titleCell/title
/titleInfo
...
/relatedItem
/mods
In this way, when a journal has a title, you just use the 'title'
field, and you don't need to remember the difference between
'booktitle', 'chapter', 'journal', etc... There's also the advantage
that you can support more types of references without changing the
format to add new field names.
I am proposing that we treat these cases in hCite in a way similar to
MODS instead of the way BibTeX does it. Here's what I propose for
hCite:
I propose a 'container' class name that would be attached to a nested
hCite instance to note when the nested hCite represents the containing
item for the root hCite. The journal example above would then look
something like this:
span class=hcite
span class=titleDifferent base/base mismatches are corrected with
different efficiencies by the methyl-directed DNA mismatch-repair
system of E. coli
/span
...
span class=hcite container
span class=titleCell/span
...
/span
/span
Comments?
FWIW, I have code in BibDesk that interprets this nesting scheme to
translate into BibTeX, and it works pretty well.
*note - Yes, it is also useful to know the type of the container so we
can tell if we're looking at a book or a journal, but that's a
separate discussion we'll have to have soon enough. For now lets focus
on the nesting issue.
Thanks,
-mike
--
Michael McCracken
UCSD CSE PhD Candidate
research: http://www.cse.ucsd.edu/~mmccrack/
misc: http://michael-mccracken.net/wp/
--
Michael McCracken
UCSD CSE PhD Candidate
research: http://www.cse.ucsd.edu/~mmccrack/
misc: http://michael-mccracken.net/wp/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [hCite] call for examples: language
On 2/1/07, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Michael McCracken [EMAIL PROTECTED] writes On 1/31/07, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Michael McCracken [EMAIL PROTECTED] writes - We only have two examples of pages marking up the language on the web - W3C and Amazon.com. Might that be because most if not all of the examples are from English-language websites, and that English-speakers are less likely to be aware of language of an issue, or to be working on second languages? Absolutely - I'm asking for help to correct this bias. Doh! I have some myself, on: http://www.westmidlandbirdclub.com/biblio/bb/70-465.htm Nice, those are good examples - they do mark up the language of the citation itself, but don't mention the language of the cited object (presumably because it's easy to deduce) - was that intentional or just following established practice? Also, could you add those examples to the citation-examples citation-examples-markup wiki pages (if they're not already there)? In my experience, established practice is that the language is not explicitly stated, and if it is, the case of a citation printing a title in one language that is referring to an item in a different language (eg, printing the title of a german book in english) is rare. So if the evidence confirms my suspicion that it's really rare to need to mark up the language of (for example) the book separately from the language of the words in the book's title, then can we just say that the language is inferred from the @lang property of the hcite element? (And hence, drop the 'language' field from the hCite straw format?) Thanks, -mike -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [hCite] call for examples: language
In message [EMAIL PROTECTED], Michael McCracken [EMAIL PROTECTED] writes http://www.westmidlandbirdclub.com/biblio/bb/70-465.htm Nice, those are good examples Thank you. - they do mark up the language of the citation itself, but don't mention the language of the cited object (presumably because it's easy to deduce) - was that intentional or just following established practice? Following the house style of the paper magazine in which the article first appeared. Though I am reminded that I still have to figure out which language some of them are in! Also, could you add those examples to the citation-examples citation-examples-markup wiki pages (if they're not already there)? Will do, though of course you could, too! In my experience, established practice is that the language is not explicitly stated, and if it is, the case of a citation printing a title in one language that is referring to an item in a different language (eg, printing the title of a german book in english) is rare. I may be rare, but it does happen. Mein Kampf in English is still titled Mein Kampf So if the evidence confirms my suspicion that it's really rare to need to mark up the language of (for example) the book separately from the language of the words in the book's title, then can we just say that the language is inferred from the @lang property of the hcite element? No! Only from a hreflang attribute, if present. Note my previous examples. (And hence, drop the 'language' field from the hCite straw format?) I still don't think that that are anywhere near enough examples, especially of non-English-language sources, to be confident that it's not widely used. -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation: next steps?
On 8/29/06, Tantek Çelik [EMAIL PROTECTED] wrote: This is a good summary to date and deserving of being captured on the citation-brainstorming page. I agree. I think the fundmental last hump to get over is the choice between a largely monolithic and flat BibTeX-like approach, and a more modular and relational DC-like approach. The choice is crtiical because it has significant implications to the flexibility of hCite. On the nesting example, though, this would be the more typical case (chapter in a book, rather than vice versa), and one could forego typing: div class=hcite div class=chapter span class=titleChapter Title/span div class=isPartOf span class=titleBook Title/span /div /div /div To me typing is nice, but not critical, paricularly if the rest of the data is sound. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite status and next steps
On 8/31/07 1:17 PM, Jason Calabrese [EMAIL PROTECTED] wrote: I'm going to be using hCite in 1 of the products that I work on. Since it will be only used interally for now I'm not going to wait for it to become a recommended specification. I do plan to stay current though. It looks like there are 3 primary issues now. 1) Identifiers 2) Types/Formats 3) Nesting We're going use the uid class with nested type/id elements for identifiers. For my use the type/format and citation nesting aren't needed so I'm going to ignore them for now. Are there any other open issues? What is being done to resolve the issues? Let me know how I can help. Hi Jason, Since the citation microformat is still very much underdevelopment, I'm redirecting your query to the microformats-new mailing list, where formats in progress are discussed. Please sign up on microformats-new. http://microformats.org/wiki/mailing-lists#microformats-new Thanks much! Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] hCite nesting (citation/bibliography/collection/collections)
Aloha microformaters, Individual citations are often collected within a document as a bibliography (references). Bibliographies from the library/institutional perspective are organized in collections (either the references or the actual items referenced. Another example of collections of references would be the references across a number of papers, collected as a group. Question: is there a set of semantic containers that could identify a bibliography within a given document, as well as a collection of bibliographies across documents? -- Sincerely, Jeff McNeill http://jeffmcneill.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation: next steps?
Bruce, thanks for clearing that up.
On 8/29/06, Bruce D'Arcus [EMAIL PROTECTED] wrote:
Mike,
On 8/29/06, Michael McCracken [EMAIL PROTECTED] wrote:
Do you just mean the ability to mark up a relation between two citation items?
For instance, if BibTeX had a convention of things like this:
@inbook{chapterkey,
title=chapter 1,
cites=articlekey,article2key,...,
partof=bookkey}
[... snip ...]
Would you consider that relational? That kind of thing fulfills what I
think you want, but I'd like to know if you're talking about something
else too.
Yes, I'd frankly forgotten about macros, but they achieve the same
thing I am after.
I think you might actually be thinking of crossref here, not bibtex macros.
Macros are just string substitution - they do this:
@string{acm = Association for Computing Machinery}
@misc{k, title=t, publisher= acm}
(note the lack of quotes around acm)
while crossref allows (single) inheritance of fields from one item to another:
@book{k1, editor= foo, title = book}
@inbook{k2, author=bar, chaptertitle = chapter, crossref=k1}
then the chapter item 'k2' is typset with title=book and chaptertitle=chapter.
I was more referring to the standard BibTeX fields, where you end up
with stuff like:
journal=ABC Journal
...or:
book=Book Title
This is what I object to as a basis for hCite. It effectively means
that whenever you need to support a new kind of resource, you need to
invent a new field name to describe the same thing: a related title.
OK, I understand. And I agree it's a bad thing - I am expecting the
microformat to deal with this by nesting items, but in a slightly
different way from what either you or Brian just mentioned. Here is
what I was expecting:
div class=hcite
span class=titleChapter Title/span
div class=hcite container
span class=titleBook Title/span
/div
/div
I like this option because we aren't requiring a type, we don't need
to define enumerated lists of properties, and it's still clear what
the association is.
We could try the following for the optional type element:
div class=hcite
span class=typeBook Chapter/span
span class=titleChapter Title/span
div class=hcite container
span class=titleBook Title/span
/div
/div
And although it looks a little awkward, it works. I'm not sure this is
the best way to do it, but I do think that types should be available,
but optional.
As for what happens if the type isn't in there in this case, I suspect
that most citation formatting solutions would still generate something
reasonable from this data because it is clear it is something
contained by something, and there's a decent chance of finding a good
default for that.
BTW, I used title here because 'fn' just seems awkward for a title,
but I'm not very concerned about it.
ISTR that you've also described BibTeX's model as flat because author
names in BibTeX are somewhat underspecified, but since a citation
microformat will use hCard, that's not an issue here, right?
Right. I think hCard is nice improvement on the BibTeX contributor
representation.
In terms of modular I am referring to the fact that there is very
little that is specific to citation metadata. Properties like title,
subject, format, etc. can be used to describe a whole range of content
beyond citations.
It therefore seems to be more sensible -- both generally, as well as
WRT to microformat practice -- to isolate the general pieces and give
them a name (like, for example, hDC), and end up with an hCite format
that mostly borrows from those more general formats (hDC, hCard, and
maybe hCal).
But this is less of a concern for me. It wouldn't be the end of the
world for others to borrow from hCite.
I agree, it seems like microformat practice would have us borrow as
much as possible from elsewhere. I think modular is a pretty
overloaded term, and I was thinking in terms of software modularity,
which didn't make a lot of sense.
I'm not convinced that a formalized Dublin Core microformat class set
is necessary for a good citation microformat, and I do think it'd be a
distraction to getting the main goal completed.
I'd like to see a citation microformat use hCard for people,
certainly. The more rich information we get about people from a
citation, the better.
As for using hCalendar, I think that would be great to mark up
conferences, meetings, etc, in citations, but I don't think a citation
microformat should *require* it. According to the hcard-authoring wiki
page, a minimal hCalendar requires a summary, start date and end date
or duration. I almost never see end dates or durations being published
for citations in current practice, and I think requiring a valid
hCalendar would make it harder for publishers to adopt the citation
microformat.
-mike
--
Michael McCracken
UCSD CSE PhD Candidate
research: http://www.cse.ucsd.edu/~mmccrack/
misc: http://michael-mccracken.net/wp/
___
microformats-discuss mailing list
Re: [uf-discuss] Easy book citations
On 7/30/06 10:35 AM, Simon Cozens [EMAIL PROTECTED] wrote: Tantek ?elik: http://microformats.org/wiki/process Second, the folks working on the citation microformat to date have done *a lot* of work along the lines of the process which I recommend you read to understand the current state of progress: http://microformats.org/wiki/citation-examples http://microformats.org/wiki/citation-formats http://microformats.org/wiki/citation-brainstorming http://microformats.org/wiki/citation-faq Oh, I've read it all. Excellent. I'm just of the opinion that following process, collating examples, performing analysis, holding discussion, forming consensus, trialling implementations, reviewing implementations, and issuing specifications is a way to ensure that nothing gets done, ever. Not true. hReview was very successfully developed, deployed, and is now adopted widely per the process. The citation process started a year ago. There's still, apparently, nothing I can use today - at least, nothing better than the ad-hocery I just created. Citations are *particularly* difficult given how many smart people have tried to solve this particular problem in the past. I do think that we are getting *very close* to a draft hCite, and perhaps it is time that we as a community focused on making that happen in the next few weeks. What if we set a goal for hCite 0.1 of August 30? Is that reasonable? In addition, I definitely encourage you to continue with the ad-hoccery and experimentation with your own site and content. That's exactly the kind of experience that can help with making a practical microformat. Thanks much for your input, efforts, and for bringing up the citation microformat again. Sometimes is just takes *one more* person to bring something up before it is solved. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [citation] citation root element
On 1/11/07 11:16 AM, Tim White [EMAIL PROTECTED] wrote: - Original Message From: Michael McCracken [EMAIL PROTECTED] I agree, 'citation' is clearer - can we vote on this? + 1 for citation -1 for citation, it is too generic for a root class name. I've been trying to capture the methodology used to date for naming in microformats here: http://microformats.org/wiki/naming-principles I started to write a few words on microformats root class names in particular here: http://microformats.org/wiki/naming-principles#Unique_Root_Class_Names Unfortunately most of the actual methodology content for root class names in particular is captured in my brain dump of hCard parsing here: http://microformats.org/wiki/hcard-parsing#root_class_name There is some history in the mailing list on this as well, but as is the case with email lists, it is difficult to find/search out. If you look at other established / adopted microformats, you'll see that they have fairly unique-ish root class names as well. hCalendar - vevent, vcalendar (taken from RFC2445) hReview - hreview (by pattern extension) xFolk - xfolkentry (I would have picked just 'xfolk' today, not sure why we went with xfolkentry) hListing proposal - hlisting I believe when Rohit Khare first proposed coming up with a citation microformat back in 2005 May at the WWW2005 conference in Tokyo, he used hBib or hCite (I don't quite remember, perhaps Rohit will see this and speak up) as a candidate name for the microformat. Thus here is another suggestion, based on what I remember of Rohit's idea, for the root class name for the citation microformat: hcite Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite elevator pitch and my bibliography generator
Henri Sivonen wrote: I needed a .bib-based bibliography generator for XHTML, so I wrote one with help from a friend who had developed a .bib parser. The output of my generator can be seen at http://hsivonen.iki.fi/thesis/html5-conformance-checker.xhtml#references I've wrapped the values of .bib fields in elements whose class name is the .bib field name. I did it just in case. I don't have any consumer use case for those class names. It was just super-easy to generate them. My use case (publishing an academic paper with a bibliography) is not mentioned as a use case at http://microformats.org/wiki/citation-brainstorming . More to the point, the wiki has no consumer use case for my publication use case. Does this mean that hCite is not for me at all? Not at all. You are using the BibTex format, which is covered in the citation formats http://microformats.org/wiki/citation-formats If hCite is for me, what's the elevator pitch convincing me to put more effort into my generator? What benefits should I expect if I do? Is hCite mature enough to be implemented yet? The citation microformat is a work in progress at this stage, so it's not mature enough for programs to extract information from it, yet examples of current use are being asked for at http://microformats.org/wiki/citation-examples so that most popular uses will be catered for. The benefits are that people visitng your content with next generation tools wil be able to easily extract and use the information in more interesting and useful ways. Tantek has a recent presentation about the big picture of microformats at http://tantek.com/presentations/2007/02/microformats/ Moreover, is it even possible to generate hCite from my source data (http://hsivonen.iki.fi/thesis/dippa.bib) without sacrificing the presentation that I want and without potentially generating bogus markup for personal names? One of the big ideas behind the use of microformats is that it will allow you to markup the content on your page without modifying the presentation of it. For example, my source data does not encode explicitly the given name, the family name and other stuff that isn't quite neither. As far as I can tell, it is impossible to tell heuristically that the middle token in these two names is semantically different: Gavin Thomas Nicol Henrik Frystyk Nielsen Those issues haven't yet been covered for for the citation microformat. It may be possible for for a generator to parse through them and extract the appropriate information though. For example, honorific-prefix and honorific-suffix are a rather short list. Then after those, the given name, family name and additional name could be extracted in that particular order. -- Paul Mark Wilkins New Zealand Tourism Online [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 109 Tuam Street Level 1 Christchurch 8011 New Zealand +64 3 963 5039 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite elevator pitch and my bibliography generator
(Sorry about my frustrated tone. I always get frustrated when I try to extract implementation directions from the wiki and fail. This isn't the first time. And I can read specs in general.) On Mar 10, 2007, at 23:10, Paul Wilkins wrote: Henri Sivonen wrote: I needed a .bib-based bibliography generator for XHTML, so I wrote one with help from a friend who had developed a .bib parser. The output of my generator can be seen at http://hsivonen.iki.fi/thesis/html5-conformance- checker.xhtml#references I've wrapped the values of .bib fields in elements whose class name is the .bib field name. I did it just in case. I don't have any consumer use case for those class names. It was just super- easy to generate them. My use case (publishing an academic paper with a bibliography) is not mentioned as a use case at http://microformats.org/wiki/citation-brainstorming . More to the point, the wiki has no consumer use case for my publication use case. Does this mean that hCite is not for me at all? Not at all. You are using the BibTex format, which is covered in the citation formats http://microformats.org/wiki/citation-formats Sure, but considering that I share my .bib, should I expect people to want to scrape my (X)HTML-formatted bibliography? If hCite is for me, what's the elevator pitch convincing me to put more effort into my generator? What benefits should I expect if I do? Is hCite mature enough to be implemented yet? The citation microformat is a work in progress at this stage, so it's not mature enough for programs to extract information from it, I guess this means that I shouldn't try to support hCite on the generator side in my thesis considering that the document should go final on the first week of April. Would it be of any use to anyone if I wrapped the name of each author/ editor in a span class='fn' if I otherwise leave my markup the way it is now? The benefits are that people visitng your content with next generation tools wil be able to easily extract and use the information in more interesting and useful ways. So basically, my effort would not be about catering to specific realistic foreseeable use cases. Instead, it would be about putting data out there in case someone figures out a use case later on. Tantek has a recent presentation about the big picture of microformats at http://tantek.com/presentations/2007/02/microformats/ I think I know the base theory. I am interested in practical use cases and implementability in this particular case. Moreover, is it even possible to generate hCite from my source data (http://hsivonen.iki.fi/thesis/dippa.bib) without sacrificing the presentation that I want and without potentially generating bogus markup for personal names? One of the big ideas behind the use of microformats is that it will allow you to markup the content on your page without modifying the presentation of it. Somehow, I was under the impression that hCite required bibliography items as lis instead of dt/dd pairs (which is what I use and what W3C and WHATWG specs use). For example, my source data does not encode explicitly the given name, the family name and other stuff that isn't quite neither. As far as I can tell, it is impossible to tell heuristically that the middle token in these two names is semantically different: Gavin Thomas Nicol Henrik Frystyk Nielsen Those issues haven't yet been covered for for the citation microformat. What I'm trying to say is that I think hCite should allow names to be marked up as formatted names tossing the deformatting problem to the consumer. After all, one of the most popular bibliography data format, BibTeX, stores formatted names. It may be possible for for a generator to parse through them and extract the appropriate information though. For example, honorific-prefix and honorific-suffix are a rather short list. Then after those, the given name, family name and additional name could be extracted in that particular order. Using heuristics in the generator to make explicit metadata statements is generally a bad idea. If the result is wrong, it still pretends to be authoritative. If heuristics are involved, the input to the heuristic should be sent and consumers should be able to compete on how good their heuristics are. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: one citation microformat use case (Michael McCracken)
I agree that the use of hAtom + citation, or even Atom + citation (hCite?) would be a good method to syndicate citation formats. The discussion of citations has been kicking up and then dying a number of times, and I take some of the blame as one of the people who'd like to push the format along not taking enough initiative. I think the most difficult part of the hCite discussion is framing our 80/20. Most bloggers and less formal writers only define references to other web sites as a single link, without much in the was of data to be marked up by a Microformat, where as academics seem to be looking for a locator and authenticity-validator not unlike MLA or Chicago, while librarians and others have been talking about including even more data in order to form a complete (pardon the jargon pun) framework for resource description. I think the problem that hCite would be trying to solve, however, would be the current inability to create a reference (hyper- or not) to another work in a way that comports validity information to the reader *without viewing the work*. hCite would be an attempt to standardize that process and therefore allow both people and tools to better understand the information. -- Ryan Cannon Interactive Developer MSI Student, School of Information University of Michigan http://RyanCannon.com/ On 11 Feb 2006, at 3:00 PM, microformats-discuss- [EMAIL PROTECTED] wrote: Message: 2 Date: Fri, 10 Feb 2006 19:25:48 -0800 From: Michael McCracken [EMAIL PROTECTED] Subject: [uf-discuss] one citation microformat use case To: microformats-discuss@microformats.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Hi, I just found the recent conversations about a citation microformat, and saw that the discussion slowed down around the same time someone asked about what problem we're solving. I'd like to add my two cents: I have a particular use case in mind: I would like to have my publications list on my home page have enough detail to reconstruct at least a BibTeX entry from it, and ideally something richer. I'd also really like to be sure that there's an element that's a link to a hard-copy of the referenced item for download, if available. Given such a microformat, I'd add support to BibDesk to generate it from BibTeX (and our upcoming database format), and support to add items from a web page directly to a database in BibDesk. I would also like to be able to subscribe to a page with data in this format, so I'd know when new publications were added. So, I'd like to hear opinions (since I'm new to the idea of microformats) on how to support subscriptions with the citation format, and whether or not it'd be best done by also using hAtom. I've been wanting to add this kind of support to BibDesk for years, and the number of citation metadata formats has made it difficult to decide on a good path to take. Thanks, -mike -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/blog/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] hCite intra-document reference
Aloha microformaters, Within given documents, especially academic journals articles, but also widely used in books, there are citations 'in-line', such as APA format (Author, YEAR), which are intra-document references to a more complete bibliography/references, at the end of articles, chapters, books, or proceedings. (Sometimes references are referred to by a footnote.) Would it be plausible to use an include pattern[1] to provide in-line citation and more complete citation/bibliographic reference? This would also support the wikiref template for mediawiki[2]. [1] http://microformats.org/wiki/include-pattern [2] http://en.wikipedia.org/wiki/Template:Wikiref -- Sincerely, Jeff McNeill http://jeffmcneill.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
On Nov 14, 2006, at 3:04 PM, Scott Reynen wrote: I'd say it's not a use case at all, as no on has really described how this markup would be used by parsing applications. Does the it's to which you're referring, Scott, mean hCite for a reviewed book in general, or marking up page numbers specifically? If it's means hCite for the book in general, I'd say it is a use case, from my understanding of hCite. Especially if I'd like to extract the bibliographic data of a book that is being reviewed. I assume that's how the markup would be used by parsing applications, but I'll leave that question to those with more expertise than I. If it's means markup for page numbers, then I can see your argument. I'm starting to see that page count might be out scope, but I'm still open to it. What exactly would we gain from this markup in terms of functionality? If you're referring to my question about page numbers, perhaps nothing. I'm totally fine with leaving it blank, or not including it within hCitation; I point out reviews as another example of how they're used, so the community could consider it. I only want to make sure that, if in fact page count is out of scope, do we simple ignore it in the markup? My understanding of why page counts exist in book review bibliographic information is that it is a legacy from older problems with knowing which book is the right book, or the book your referring to; I might refer to a version that has, say, 438 pages, but there might be another print run that had, for various reasons, 420 pages. This is so much a problem anymore, so maybe it isn't a problem for hCite. If it's in a review and it's describing the item you're reviewing, I'd say it belongs in hReview's description field. I completely agree. From my understanding, that information included inside the DESCRIPTION field in hReview could be marked up with hCitation. hReview isn't, however, listed in the Modularity section of the citation page, though I imagine it could be.[1] Is there a reason why hCite could not be used in a book review marked up in hReview? If there is a need to describe page count more specifically, I'm still not clear what it is. Searching books by page count? If marking up content to make it searchable is the primary purpose of hCitation, then I'd agree that page count is out of scope. This leads me to ask: is this the primary purpose of hCitation to mark up searchable information? I'm not sure that people search solely by other information that is included in hCitation (publisher, location of publisher,volume,edition). Best, Jeremy [1] http://microformats.org/wiki/citation#Modularity ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: [hCite] call for examples: language (Andy Mabbett)
On Feb 2, 2007, at 11:13 AM, Andy Mabbett wrote: I may be rare, but it does happen. Mein Kampf in English is still titled Mein Kampf So if the evidence confirms my suspicion that it's really rare to need to mark up the language of (for example) the book separately from the language of the words in the book's title, snip (And hence, drop the 'language' field from the hCite straw format?) I still don't think that that are anywhere near enough examples, especially of non-English-language sources, to be confident that it's not widely used. I'm going to suggest that a language field--for works where the title incorrectly implies the resources language--sits outside of the 80/20 for a citation microformat for a number of reasons: 1. According to our current evidence it's very rare 2. In some cases where it does occur (online resources) common HTML constructs (@hreflang) fulfill the need completely. 3. In many remaining contexts, language differences are unimportant for the user. E.g.: a scholar chasing the citations of a critique of French literature written in English will likely already know French. -- Ryan http://RyanCannon.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [hcite] date-published
On Feb 20, 2007, at 8:44 PM, Tim White wrote: I vote for leaving it date-published. It really doesn't matter when consumers get their hands on a published piece, all that matters is when it is (claimed to be) published. I also vote for leaving it date-published. Though not really arguing against Tim's reasons, there are cases in which citations can have a date published and a date visited or accessed. When citing websites and web pages, for instance, some citation formats display date published and date visited, when that information is available. More often than not, citations for websites and web pages ask for date visited instead of date published. That said, should there also be a date-accessed or date-visited value for hCite? Jeremy ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] hCite progress
I have had a few free cycles this last week so i have been making some head-way with the citation microformat. I took some to to re-organize the XSLT code, so now it should be alot easier to create new transformations. So i have added Dublin Core and RIS to possible output types. This is the new home for all the citation transformations: http://suda.co.uk/projects/microformats/hcite/ Once we get our version system setup for a citation test suite, i will be creating HTML and cite-specific formats and will need some feedback on other things to check-in (anyone else is more than welcome to create some tests too *hint* *hint* :) ). There have been a few hiccups that i am starting to uncover - so any guidance is welcomed. 1) The term Pages i think that actually has two meanings which i have confused in the implied schema. The first being This book is 45 pages long which is metadata about the book, and is in the realm of media-info microformat. Then there is this sites pages 43-45 meaning a location. So now we need figure out what we are to do? does the first metadata become span class=page-count45/span and the citation stay pages or do we have start-page and end-page or something else? Some systems use pages as a string 43-45 others have it broken out into SP (start page) 43 EP (end page) 45. I'm not sure how they handle references in something like a newspaper where the article starts on page 1 and then jumps to page 43... that is not start-end, but a list of pages. Then that leads to our singularization of plural terms. In vCard it is categories (plural) but we use category singular and just let you have multiple instances... can pages go the same way? the first instance of class=page is the start page, and the last instance if the last page? Any suggestions? 2) one of the manditory properties across several different citation formats is TYPE. Is this a Book, Journal entry, Thesis, Video, etc. Usually and enumerated list of values. The issue is that EVERYONE does it differently... so should hCite have an enumerated list of types such as Thesis and that maps to bibTeX mastersthesis and RIS THES or should that be something transforming apps handle. I'm not sure how to handle this (i'd prefer not to use enumerated lists of possible values) but if we allow open values, and i write span class=typeThesis/span and that gets converted to a citation format, it will fail most of the formats because the string Thesis is not a valid type. I also think it is silly then to do span class=typeTHES/span and then be valid for only one format. This is where a hard-coded list of values in hCite would help, hCite's thesis can be interpreted into various formats' TYPE values - although i don't like that idea, but don't have any other suggestions except to ignore it and let the implementor figure it out? Any comments? Also, i have wiki-fied several citation examples from a previous email, with accessed date. I have not updated any implied-schemas to reflect any changes yet. I haven't outputted the accessed date into BibTeX, RIS or Dublin Core because i don't know what field they equate too? Alot of this will get flushed out when we start building examples and tests. All input is welcomed. Thanks, -brian -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
On Nov 13, 2006, at 3:11 PM, Bruce D'Arcus wrote: Page count is only relevant to publishers and book stores (maybe). Page count is also important in academic and non-academic reviews of books, specifically when the review prints the information of the book in question. See the NY Times review of _Ghost Map_ [1] as one example. THE GHOST MAP: The Story of London’s Most Terrifying Epidemic — and How It Changed Science, Cities, and the Modern World. By Steven Johnson. 299 pp. Riverhead Books. $26.95. This is a very common citation format for book reviews. I'd be glad to gather evidence on this if need be. Do we want to then include ways to encode the length of a CD or a DVD film or an HTML document? I think not, particularly when there are more important issues to worry about. Me not knowing what other important issues are aside, I do think we should include ways to encode the length of a CD or DVD...length of films, music, and other audio/video media is included when citing them. That said, the citation-examples page does not include these media.[2] There isn't a standard citation format that I'm aware of that tries to include the length of an HTML document. Then again, I'm only familiar with Chicago-style citations. The Chicago format for citing an online MPEG would be: Weed, A.E. _At the Foot of the Flatiron_. American Mutoscope and boigraph Co., 1903; 2 min, 19 sec.; 35mm; from Library of Congress, _Early Motion Pictures, 1898-1920_. MPEG, http://hdl.loc.gov/ loc.mbrsmi/lcmp002.m2a33981 (accessed November 14, 2006). Lots of different stuff included in this citation: format, length, access date. Could you hCalendar to mark up the access date. My concerns with media-info are outlined below: On Nov 13, 2006, at 10:17 PM, Scott Reynen wrote: Page count still looks out of scope to me for hCite, and closer to the type of information (i.e. file size) being discussed in media- info. The only problem I see with this is that, according to the citation- brainstorming page, there is a significant difference between citation and media-info: media-info describes information about content embedded or inline in the current document whereas citation is a reference to something explicitly external.[3] Especially with the example citation I give above, even though I'm citing an audio- visual source, because its external from my document, I should use hCitation, NOT media-info, at least according to the current definition on the wiki. I do think that page counts should be accounted for, in some way. Whether that way is in hCite or through a redefinition of media-info (or some other options). Thanks, Jeremy Boggs [1] http://www.nytimes.com/2006/11/12/books/review/Quammen.t.html? ref=review [2] http://microformats.org/wiki/citation-examples [3] http://microformats.org/wiki/citation- brainstorming#Citation_vs._media-info ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Visual Art Titles Microformat Proposal
On 10/21/06, Jeremy Boggs [EMAIL PROTECTED] wrote: It sounds like this might be a good addition to the citation microformat effort [1] and related pages. [2] I think the majority of the discussion/efffort for the citation has focused on text documents, but a case could certainly be made (and one that I would support) that the citation microformat should include works of art and other visual works (photographs, sculptures). Yes. As you mention, some of the basic components (title, creator, date) are already in use in the citation microformat. Well, actually, title is not going to be included, because of the no-namespace problem. E.g. it would conflict with hCard title, which is different. But fn is essentially used to achieve the same thing (if really awkwardly). There are a few other components (medium, size, unit of size) that might not be included. Medium and/or format ought to be included in hCite, since that information typically gets included for any non-physical-text items. E.g. if you cite a film, you might include DVD. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
On Nov 14, 2006, at 3:57 PM, Jeremy Boggs wrote: On Nov 14, 2006, at 3:04 PM, Scott Reynen wrote: I'd say it's not a use case at all, as no on has really described how this markup would be used by parsing applications. Does the it's to which you're referring, Scott, mean hCite for a reviewed book in general, or marking up page numbers specifically? Neither. I was referring only to page count (which is different than page numbers). I'm starting to see that page count might be out scope, but I'm still open to it. I'm certainly open to it too. I'd just like to see some reason for including additional markup, some way it actually helps us do anything, so we're not just adding markup for markup's sake. What exactly would we gain from this markup in terms of functionality? If you're referring to my question about page numbers, perhaps nothing. I'm totally fine with leaving it blank, or not including it within hCitation; I point out reviews as another example of how they're used, so the community could consider it. I only want to make sure that, if in fact page count is out of scope, do we simple ignore it in the markup? Yes. Nearly every type of microformat published in the wild contains content that isn't part of the microformat's purpose. Parsers just ignore this unrelated content. But it can still be intermingled in the HTML. My understanding of why page counts exist in book review bibliographic information is that it is a legacy from older problems with knowing which book is the right book, or the book your referring to; I might refer to a version that has, say, 438 pages, but there might be another print run that had, for various reasons, 420 pages. This is so much a problem anymore, so maybe it isn't a problem for hCite. If that were a common problem I think it would be a compelling reason to include page counts. But if it's just an edge case, hCite can still be useful to the 80% (or more) cases where page count is irrelevant, and people can still read the page count where it's relevant even if machines can't. If it's in a review and it's describing the item you're reviewing, I'd say it belongs in hReview's description field. I completely agree. From my understanding, that information included inside the DESCRIPTION field in hReview could be marked up with hCitation. hReview isn't, however, listed in the Modularity section of the citation page, though I imagine it could be.[1] Is there a reason why hCite could not be used in a book review marked up in hReview? I don't see any. You have to cite a book before you can review it, right? If there is a need to describe page count more specifically, I'm still not clear what it is. Searching books by page count? If marking up content to make it searchable is the primary purpose of hCitation, then I'd agree that page count is out of scope. That was just a question, not an attempt to declare the scope of hCite. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
On Nov 16, 2006, at 5:09 PM, Andy Mabbett wrote: It seems to me that the following properties might be recorded: This is a nice list, Andy. Thanks! the total number of pages in a publication (be that a book, magazine, thesis, etc.) the total number of pages in a publication series (be that a set of books, a year's worth of magazines, etc.) the total number of pages in a cited article, book-chapter, or other section of a publication I've only seen total number of pages listed for books, but if we do end up including that for books, I don't see why we couldn't also include it for other kinds of publications. the unique single page of a cited section the start page of a cited section the end page of a cited section the page run (e.g. 3-4, 6, 8) of a cited section the unique single page of a quotation the start page of a quotation the end page of a quotation the page run (e.g. 3-4, 6, 8) of a quotation It seems like these sections would go together well. That is, a cited section and a cited quotation would involve pretty much the same reference structure. Whether I paraphrase a section on page 4 of Brian's _Using Microformats_ book, or get a direct quote from that page, I would use: (Suda, 2006: 4) or Brian Suda, _Using Microformats_ (2006), 4. or some variation of that. Citation standards don't differentiate by what specifically is being cited (paraphrased section or direct quote)...at least the standards that I'm aware of. I would also add to this list: the page run (e.g. 1-41) of a cited article, book section, or other section of a publication. Which is different from the total number of pages in an article. At the very least, if we include some, but not all. of those in hCite, we should name them in such a way as to make it possible, preferably simple, to include the others in future. This seems reasonable. using the abbr class=pages title=20-3020 to 30/abbr model seems to work well. Maybe differentiating how pages are being used shouldn't be done in the code wrapped immediately around the pages, but in the container in which the pages are listed. So for marking up a work that includes all the pages: div class=bibliography div class=hciteJohn Doe, Lorem Ipsum, abbr title=20-30 class=pages20-30/abbr/div div class=hciteJane Doe, _Dolor Sit Amet_ abbr title=455 class=pages455/abbrPp./div /div Parsers would know that, because HCITE is inside bibliography container, it is listing all the pages in a publication. For a book, pages would refer to the total number of pages. In contrast, specifying a specific page in a work: div class=citation div class=hciteJohn Doe, Lorem Ipsum, abbr title=20-23 class=pages20-23/abbr/div div class=hciteJane Doe, _Dolor Sit Amet_ abbr title=320 class=pages320/abbr/div /div Parsers would know that, because an HCITE is inside a citation container, it is listing only those pages being cited, and not the entirety of the work. And perhaps that hcite that only refers to specific pages could somehow be connected to the bibliography hcite of the same publication. Bibliography and citation may not be the best terms or most flexible, but it makes sense to me to put the hCite in a specific context (bibliography, footnotes/endnotes, etc...) and go from there. Maybe this is too complicatedThoughts? Another option might be to specify, inside the class attribute with pages, the kind of pages listing it is: Specific pages cited: div class=hciteJohn Doe, Lorem Ipsum, abbr title=20-23 class=pages cited20-23/abbr/div Listing of all pages in a work: div class=hciteJohn Doe, Lorem Ipsum, abbr title=20-30 class=pages all20-30/abbr/div Saying that the work is x pages long: div class=hciteJohn Doe, _Lorem Ipsum_ abbr title=10 class=pages total10/abbr/div These may not be the best class names either, and also too complicatedThoughts? Best, Jeremy ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Re: [uf-discuss] hCite progress
On 11/13/06, Chris Messina [EMAIL PROTECTED] wrote: In terms of type... How important is that designation? If you have an open-ended list, isn't that similar to a tag or is there real consequence to its type-designation? Well, TYPE seems to be pretty important, it is manditory by (atleast) RIS and BibTeX so far. Both of those have enumerated lists of possible values, which there duplicate values (e.g. Book, Thesis, etc.) but they use different terms (e.g. mastersthesis or THES) so what gets used for the hCite type? or do we create our own list that maps to the 80% of common types. We could use tags, but then we are still picking out the tag portion as the TYPE value. You could do that already now with Keywords in hCite and Skills in hResume and Categories in hCard. And the value that gets extracted would need to still have to match to some sort of logical citation type. I ate a a href=/tags/watermellon rel=tag class=typewatermellon/a yesterday. I'm not sure how that helps us? whereas: This is a a href=/tags/book rel=tag class=typebook/a i read yesterday. That helps on two fronts, #1 we have an established type (book) and #2 we get bonus points for making it a tag so now we can search on all books! That's great for a blog, but that tag space on Amazon wouldn't really narrow things down much :) -brian -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] [hcite] indentifier
Identifier is, Per the straw man[1]: An (not necessarily globally unique) identifier, such as a cite-key, pubmed ID number, or simply the reference number or string within a publication ([1] or [CLRS2001]) I wrote an hCite export template for BibDesk*, and used the identifier (cite-key) as the id attribute on the root element. I'll argue that `identifier` is not data that needs to be accessible to humans, and we already have a semantic equivalent in HTML. Here's an example. The class=book is just a CSS hook to differentiate books and articles: cite class=book hcite id=Lippmann:1997fk span class=creator vcard span class=fn n span class=family-nameLippman/span, span class=given-nameWalter/span. /span /span span class=titlePublic Opinion/span span class=publisher vcard span class=adr span class=locality regionNew York/span: /span span class=fn orgFree Press/span /span span class=date-published1997/span. /cite Comments? * The template is a total hack and needs to be updated. Contact me if you'd like to see it in it's current state. [1]: http://microformats.org/wiki/citation- brainstorming#Working_straw_schema -- Ryan Cannon Interactive Developer MSI Student, School of Information University of Michigan http://RyanCannon.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [hCite] dates
On 1/17/07, Michael McCracken [EMAIL PROTECTED] wrote: Looking at the examples on citation-examples, I find the following frequencies of marking up a date: publication date: 21 date accessed: 3 date copyrighted: 1 (from OCLC worldcat online) I just added date-accessed to the working straw schema. Certainly all three are useful, but can we find more examples for the last two? I'd be more comfortable having a 'date copyrighted' field in the uf if there was more than one real-world example on the wiki. --- the other senario is to strip this down to the basics for a version 1 and NOT include those lesser used dates, then use hCite for awhile, see what falls down and itterate? If there is another date field that you think is useful, now would be a good time to add examples of its use and discuss it. --- the best way to do this is not to just suggest a datetime you want, but as Michael mentioned, fine examples! Also, I assume the date fields should use abbr: abbr class=date-published title=ISOdatedate text/abbr however, many publications have only years, or just years and months - it would be good to have a recommendation about what to do in that case. Would span class=date-published2007/span be acceptable, or should we insist on the full ISO date? --- is a valid year[1]. The tricky things is when you are converting an hCite to a variety of different non-HTML formats then a Month Day might be required and can be added as 01-01 (but i'm open to other interpretations) The problem is how we would know to ignore the month and day in the full date if they're just there to satisfy parsers. --- in my start of crafting XSLT files i was converting hCite to BibTeX. BibTeX has seperate Month, Day, Year and the parser extracts those independatly from a single ISO date. If those are NULL then the first of the Month,Year are valid. There was the same discussion awhile about about how to mark-up Fall, Spring, ... Then there is the weird senario in the UK where some Magazines come-out a month before their publication date. -brian [1] - http://www.w3.org/TR/NOTE-datetime -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: [hcite] nesting container elements
Michael McCracken wrote: We need to deal with bibliographic details for things like chapters in a book, articles in a journal or magazine, and issues in a series. For designing a format, the main problem is that there are duplicate items that need to be scoped - for instance, both the article and the journal have a title. I actually brought this up in December in response to Brian's straw format[1], but the words I thought to use were collection or in. I like in largely because some citation formats actually use that word to describe this type of relationship: The American Chemical Society: [2] Almlof, J.; Gropen, O. Relativistic Effects in Chemistry. In Reviews in Computational Chemistry Lipkowitz, K.B., Boyd, D.B., Eds.; VCH: New York, 1996; Vol. 8, pp 206-210. American Psychological Society: [3] James, N. E. (1988). Two sides of paradise: The Eden myth according to Kirk and Spock. In D. Palumbo (Ed.), Spectrum of the fantastic (pp. 219-223). Westport, CT: Greenwood. Chicago Style: [4] Repgen, K. 1987. What is a 'Religious War'? In Politics and society in Reformation Europe, edited by E. I. Kouri and T. Scott, 311-328. London: Macmillan In, being a preposition, sounds kludgy on its own, but reads very well within the code: p class=hcite ... span class=in hcite .. /span /p Note too that this problem exists for other parts of citations, like publisher data: most book citations are published with the city of publication, but this is more appropriately the `adr` field of a nested hcard for the publisher. Here, nested data is appropriate to the top- level citation as well. [1]: http://microformats.org/wiki/citation-brainstorming#Book (toward the end of the section) [2]: http://www.library.ubc.ca/scieng/chem121/module3/module3_7.html [3]: http://www.liu.edu/CWIS/CWP/library/workshop/citapa.htm [4]: http://www.libs.uga.edu/ref/chicago.html -- Ryan Cannon Interactive Developer MSI Student, School of Information University of Michigan http://RyanCannon.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Citation: next steps?
Hi, aside from adding a few good examples of existing formats, it looks like there hasn't been any movement toward the Aug 30 deadline for hCite 0.1. Should we reschedule the goal? Also, what is the immediate next step on the path to a recommendation? Do we need to clarify the existing research on the wiki? Is anyone waiting for an answer or agreement before moving forward? Thanks, -mike -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
Andy Mabbett wrote: In message [EMAIL PROTECTED], Ross Singer [EMAIL PROTECTED] writes If you can't grab total number of pages, does your plan of absolute bird book aggregation fail miserably? I'm not sure what you think can be achieved by such an asinine comment. I think the question is whether you're already integrating other data, such as images of book covers, from other sources, or whether *all* the data about the book needs to be in the citation. Personally, I think having as much information as possible is a good thing. This is most important for 'self' hCitations, less so for 'bibliography' hCitations, where you just need enough information to identify the cited work. alf. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] [hcite] date-published
From Bruce D'Arcus on the wiki: I've mentioned more than once that date-published is misleadingly specific; too much for real world citations. Consider that many books are published in the year preceding their copyright date, which is in fact the date used for citation. I'd prefer just date and date-accessed as a first cut. --Bruce 3 Feb 2007 I agree - this maps well to current practice in existing formats I know of - they tend to not specify the type of date, instead using fields like month and year. Is anyone against changing 'date-published' to 'date'? -mike -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [hcite] date-published
In message [EMAIL PROTECTED], Michael McCracken [EMAIL PROTECTED] writes OK, I disappeared for a while there, but is it fair to summarize this thread by saying that the two field names we have the best evidence for in terms of usage on the actual web are 'date-published' and 'date-accessed'? I've been reading Wikipedia's articles and policies on citation, and it uses both; -published chiefly for books and journal articles; -accessed for citing external web pages. (Start at: http://en.wikipedia.org/wiki/Wikipedia:Cite_sources) -- Andy Mabbett I wonder what the archives, Google Groups et al will make of: span class=geospan class=latitude52.483/spanspan class=longitude- 1.893/span/span ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
Again, and I don't mean to sound dismissal: What does the inclusion of 'total number of pages' grant you here? If you can't grab total number of pages, does your plan of absolute bird book aggregation fail miserably? It seems to me that the citation aggregator would be/could be doing something useful with the citation that it has to get the user to a place where total number of pages could be learned. Knowing the full number of pages in a work brings you really nowhere closer to actually 'getting' the cited work in question. That, in my mind, is the complete 'point' and 'scope' of a citation. To help people who are looking for the work that is being mentioned to locate it for themselves, whether that be hunting them down manually (via the traditionial APA, MLA, Chicago styles) or by machine (through OpenURL). -Ross. On 11/16/06, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Scott Reynen [EMAIL PROTECTED] writes So, if page count is out of the scope of hCite, and if it turns out (from my observation about media-info) that it doesn't fit into the media-info format, would page count just not be marked up at all? What exactly would we gain from this markup in terms of functionality? The ability to scrape pages listing books, and use the results to build a page like: http://www.westmidlandbirdclub.com/biblio/warwks.htm -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [citation] citation root element
On 1/17/2007 Brian Suda said: --- i don't feel it is appropriate for us to mandate how to encode microformats. If i want to create a citation in prose inside a paragraph, then i should be able to 'hang' the class=hcite on the block-level p or div. Microformats are all about NOT changing user's behavior, but forcing the use of the inline cite element we are defining that behavior. That said, the cite element does certainly convey some additional semantics and SHOULD be used, but i would avoid MUST. This parallels the address element discussion for several other formats. -brian Complete agreement; recommend using cite but not a mandate. ~ Tim tjameswhite.com'http://www.tjameswhite.com;tjameswhite.com Food fight? Enjoy some healthy debate in the Yahoo! Answers Food Drink QA. http://answers.yahoo.com/dir/?link=listsid=396545367 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
On Nov 13, 2006, at 2:20 PM, Brian Suda wrote: But as Bruce said: start-end pages are not really important, just capture the string pages 10-50. So i think something akin to the first example here will work. One reason why a string might not be useful is capturing a citation for a specific page of a work versus capturing a citation of a work in its entirety. Its one thing to cite a specific quote from page 40 of an article in a journal, and another to cite an entire article that exists on pages 37-65 in a journal. If I were to quote something specific, or refer to a specific idea or statement in a journal article on page 40, I would use some variation of the following: John Doe, Lorem Ipsum Dolor, _Sit Amet_ vol. 81, no. 3 (2000), 40. If, however, I would want to refer to the entire article, I would use the following: John Doe, Lorem Ipsum Dolor, _Sit Amet_ 81, no.3 (2000), 37-65. I don't see how leaving pages as a simple string can account for this difference. I wouldn't want a parser to say that the article is only one page long, and that it exists only on page 40 of a journal. Granted, neither of these citations, in and of themselves, really lets the reader know whether the entire article, or just a portion of it, is being cited. In this case, start-end pages are important. I'm not really sure offhand how to remedy this, but I'll certainly think about it and offer up whatever I come up with. (I've tended to do that on this list; raise questions without offering much on solutions. My apologies.) Does anyone else have thoughts about this? Maybe it would be useful to use the include-pattern in hCite? It seems like it would be helpful to be able to include information on a work in a smaller citation. Given the example above, if I were to add subsequent citations to cite a different page of the same work, I would use something like this: 1. John Doe, Lorem Ipsum Dolor, _Sit Amet_ vol. 81, no. 3 (2000), 40. 2. Doe, 54. There are variations on a theme for this, across disciplines and citation standards. Would the include-object be useful to include specific information from the first citation to be used in the second citation? Or more broadly, would the include-object be helpful in connecting multiple citations of the same work to the more complete bibliographic information of a work? It also might be useful for the problem I illustrated above, with citing on a specific portion of a work versus citing a work in its entirety. Maybe use the include-object to include the start-end pages of a work, while showing the specific page being cited? I can come up with some example markup, if it is valid for hCite and folks think it would be useful. Best, Jeremy ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [citation]: Brian's outstanding issues 3: nesting
Sorry, it was hinted at in the first email- I should have included it in each: http://microformats.org/wiki/citation-brainstorming#Outstanding_Issues On 9/25/06, Bruce D'Arcus [EMAIL PROTECTED] wrote: First, a URL for the wiki page you are referring to would be helpful ;-) On 9/25/06, Michael McCracken [EMAIL PROTECTED] wrote: option 1: requires class names for every reference type. I don't like this option either. option 2: uses type class, but makes it confusing IMO - what if you want to include more data about the containing reference than just one element? Does the type continue to influence sibling elements until another type element cancels it out? Can't comment on the above since I don't know the context. I have another option that might work: option 3: nest ufs. I've used this a few times in examples without anyone commenting on it. Is this OK? What are the pros/cons? I have parsed HTML using a DOM traversal before, and this seems like it'd be reasonably easy to parse. It's also a little easier to write and more obvious than #2, IMO, since it's clear that the elements under the container span are all referring to the item that's of type book... span class=citationspan class=typechapter/span: span class=titlestuff/span span class=citation containerspan class=typebook/span span class=titleA collection of stuff/span I thnk that's fine, notwithstanding my other quetion about the type span (which seems even more funky in this case). Also, citation could probably be hcite? Is your other question in the other email thread? If so, I'll respond over there. I have no opinion about citation vs. hcite. -mike -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Easy book citations
On 7/30/06, Fred Stutzman [EMAIL PROTECTED] wrote: Well, of course it isn't the overwhelmingly dominant bibliographic/citation format It's not even close. If you ask 100 people in my field about BibTeX, my guess is at least 90 of them of them won't even know what you're talking about. Of course, a lot of them probbaly manually author their bibliographies (!), but still RIS and Endnote are perhaps even more widely supported formats for personal reference management. Both of those formats are based on a more general three level model. Of course, we can dream up blue-sky scenarios on how to make a better citation format. I'm sure we can do better. But if we do, we miss the boat and lose the collective value of all the software that would natively support the format. Regardless of the end result, you will need software to convert from legacy formats into and out of hCite. There is no way around that. I've done enough work on this stuff -- and worked with other developers; people like Chris Putnam on his excellent bibutils converion tools -- to tell you that it's pretty easy to design a a good format that will be easy to use, extend, and process. Nothing blue sky about it. And it won't be hard to convert into and out of BibTeX either (except, of course, where BibTeX's limited data structure gets in the way). But if you follow the BibTeX way strictly (where all properties are single values) you will end up with an hCite tha is liimited, and akward to extend. Every time someone needs to represent a different kind of resource, they'll have to go through some complicated community consensus process just to get their new ttitle, etc. propreties authorized. There really is a better way. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [citation]: Brian's outstanding issues 2:
On 9/25/06, Michael McCracken [EMAIL PROTECTED] wrote: The option of just ignoring types altogether - not including a type property at all - is certainly possible - it would make human-reading and publishing easier but automatic parsing somewhat harder. This might be a worthwhile tradeoff. I feel this is a very short-sighted decision, if it's the route hCite goes... You'd never be able to link to an appropriate copy (because you wouldn't be able to determine with any semblance of confidence what an item actually is) and I'm therefore not sure what the point of this is. I guess the way I look at it is this: the entire point of formatting a citation in a standardized way is so that another scholar can then go in and know how to find the item again to follow the first person's research. If the second scholar's /browser/ can do this work, the way that it looks on the screen is rather insignificant (much to the chagrin on the MLA and the APA, but they'll probably be happier in the long run). I've gone on record repeatedly that I don't care if hCite looks like OpenURL as long as it's easy to make something remotely OpenURL from it, but this is a fairly vital part of OpenURL... the very basic notion of knowing what something is. I would recommend that we at least use the basic the journal (journal, article, issue, proceeding, conference, preprint), book (bookitem, book, proceeding, conference, report), dissertation (or thesis), or patent that are currently defined under the San Antonio profile in OpenURL (and it's actually trivial to add other formats if necessary -- yes, that's an open invitation to you, Bruce ;)). No, you don't have to use these labels, but if you want to get the darn thing, choose something that we can map to. Because static, non-actionable lists are so last web trend. -Ross. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
I also can't see a compelling case for page counts. They aren't generally used in bibliographies, CVs, OpenURLs -- basically the important cases for markup. The only places I can really see them occurring are bookstore and library catalogs -- do they really need to be included? What purpose would it serve? I would like to make the argument for start-end page, though. If start page is being included, end page seems easy enough, and it could be useful for last mile information retrieval purposes. -Ross. On 11/13/06, Scott Reynen [EMAIL PROTECTED] wrote: On Nov 13, 2006, at 4:58 PM, Andy Mabbett wrote: I agree. It doesn't seem to help any of the use cases identified in the wiki: http://microformats.org/wiki/citation-brainstorming#Use_Cases It does: http://microformats.org/wiki/citation- brainstorming#Buy_a_copy Both Amazon and ABE cite page counts. Sure, but neither allow searching for books by those page counts that I see, so this doesn't seem to help with the stated task: Find the cited work on, for example, Amazon or ABE. Page count still looks out of scope to me for hCite, and closer to the type of information (i.e. file size) being discussed in media-info. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [hcite] date-published
2007/2/21, Tim White [EMAIL PROTECTED]: Jeremy said: Though not really arguing against Tim's reasons, there are cases in which citations can have a date published and a date visited or accessed. Most definitely. I did not mean to discount the value of date-accessed. That said, should there also be a date-accessed or date-visited value for hCite? I believe date-access is in the staw schema... yup, it's there. http://microformats.org/wiki/citation-brainstorming#Basic_Citation_Stuctures ~ Tim OK, I disappeared for a while there, but is it fair to summarize this thread by saying that the two field names we have the best evidence for in terms of usage on the actual web are 'date-published' and 'date-accessed'? I've had my mind changed about my earlier position that using 'date' would be better than 'date-published'. Vagueness of the data aside, the majority of our examples show at least an intent of describing a publication date, and I think we don't gain anything by making our field name less specific. Therefore, the schema will stay as-is on the wiki at http://microformats.org/wiki/citation-brainstorming#Working_straw_schema Comments? -mike -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: Re: RE: [uf-discuss] [citation] url field
Ironically, this sounds like another real-world (i.e. not hypothetical) example of the need to provide a way to differentiate microformats. -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael McCracken Sent: Thursday, December 07, 2006 6:05 PM To: Microformats Discuss Subject: Re: Re: RE: [uf-discuss] [citation] url field This seems to have been buried - so again, to anyone interested in hCite: I want to define a new field URL to denote an http URL that points to the location of a copy of the cited work. URIs that encode an identifier of the work can be combined with this field, but do not need to be. I understand that the name URL may overlap a bit with URI, and something like downloadlink, etc. might be more direct, but I argue that URL is the better choice because it is the most common name already in use in our examples from the web. Can we discuss this revised version of the proposal (or just vote on it?) Thanks, -mike ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation: next steps?
Bruce, do you have a canonical example that gets at exactly what you
mean by monolithic and flat vs. modular and relational? I think I used
to understand what you meant by those, but I want to be sure. Please
bear with me on this, I know I asked you a similar question a while
back, but I think that what you're asking for is actually not as
complicated as it may sound.
Do you just mean the ability to mark up a relation between two citation items?
For instance, if BibTeX had a convention of things like this:
@inbook{chapterkey,
title=chapter 1,
cites=articlekey,article2key,...,
partof=bookkey}
@book{bookkey,
title=book}
@article{articlekey,
title=article}
etc...
Would you consider that relational? That kind of thing fulfills what I
think you want, but I'd like to know if you're talking about something
else too.
ISTR that you've also described BibTeX's model as flat because author
names in BibTeX are somewhat underspecified, but since a citation
microformat will use hCard, that's not an issue here, right?
Thanks,
-mike
On 8/29/06, Bruce D'Arcus [EMAIL PROTECTED] wrote:
On 8/29/06, Tantek Çelik [EMAIL PROTECTED] wrote:
This is a good summary to date and deserving of being captured on the
citation-brainstorming page.
I agree. I think the fundmental last hump to get over is the choice
between a largely monolithic and flat BibTeX-like approach, and a more
modular and relational DC-like approach. The choice is crtiical
because it has significant implications to the flexibility of hCite.
On the nesting example, though, this would be the more typical case
(chapter in a book, rather than vice versa), and one could forego
typing:
div class=hcite
div class=chapter
span class=titleChapter Title/span
div class=isPartOf
span class=titleBook Title/span
/div
/div
/div
To me typing is nice, but not critical, paricularly if the rest of the
data is sound.
Bruce
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
--
Michael McCracken
UCSD CSE PhD Candidate
research: http://www.cse.ucsd.edu/~mmccrack/
misc: http://michael-mccracken.net/wp/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
In terms of type... How important is that designation? If you have an open-ended list, isn't that similar to a tag or is there real consequence to its type-designation? Chris On 11/13/06, Brian Suda [EMAIL PROTECTED] wrote: I have had a few free cycles this last week so i have been making some head-way with the citation microformat. I took some to to re-organize the XSLT code, so now it should be alot easier to create new transformations. So i have added Dublin Core and RIS to possible output types. This is the new home for all the citation transformations: http://suda.co.uk/projects/microformats/hcite/ Once we get our version system setup for a citation test suite, i will be creating HTML and cite-specific formats and will need some feedback on other things to check-in (anyone else is more than welcome to create some tests too *hint* *hint* :) ). There have been a few hiccups that i am starting to uncover - so any guidance is welcomed. 1) The term Pages i think that actually has two meanings which i have confused in the implied schema. The first being This book is 45 pages long which is metadata about the book, and is in the realm of media-info microformat. Then there is this sites pages 43-45 meaning a location. So now we need figure out what we are to do? does the first metadata become span class=page-count45/span and the citation stay pages or do we have start-page and end-page or something else? Some systems use pages as a string 43-45 others have it broken out into SP (start page) 43 EP (end page) 45. I'm not sure how they handle references in something like a newspaper where the article starts on page 1 and then jumps to page 43... that is not start-end, but a list of pages. Then that leads to our singularization of plural terms. In vCard it is categories (plural) but we use category singular and just let you have multiple instances... can pages go the same way? the first instance of class=page is the start page, and the last instance if the last page? Any suggestions? 2) one of the manditory properties across several different citation formats is TYPE. Is this a Book, Journal entry, Thesis, Video, etc. Usually and enumerated list of values. The issue is that EVERYONE does it differently... so should hCite have an enumerated list of types such as Thesis and that maps to bibTeX mastersthesis and RIS THES or should that be something transforming apps handle. I'm not sure how to handle this (i'd prefer not to use enumerated lists of possible values) but if we allow open values, and i write span class=typeThesis/span and that gets converted to a citation format, it will fail most of the formats because the string Thesis is not a valid type. I also think it is silly then to do span class=typeTHES/span and then be valid for only one format. This is where a hard-coded list of values in hCite would help, hCite's thesis can be interpreted into various formats' TYPE values - although i don't like that idea, but don't have any other suggestions except to ignore it and let the implementor figure it out? Any comments? Also, i have wiki-fied several citation examples from a previous email, with accessed date. I have not updated any implied-schemas to reflect any changes yet. I haven't outputted the accessed date into BibTeX, RIS or Dublin Core because i don't know what field they equate too? Alot of this will get flushed out when we start building examples and tests. All input is welcomed. Thanks, -brian -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- Chris Messina Citizen Provocateur Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable[X] ask first [ ] private ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [citation]: Brian's outstanding issues 2:
On 9/25/06, Ross Singer [EMAIL PROTECTED] wrote: On 9/25/06, Michael McCracken [EMAIL PROTECTED] wrote: The option of just ignoring types altogether - not including a type property at all - is certainly possible - it would make human-reading and publishing easier but automatic parsing somewhat harder. This might be a worthwhile tradeoff. I feel this is a very short-sighted decision, if it's the route hCite goes... A side note - I'm not in charge, I'm just loud :) hCite won't go that route unless a lot of people say it should. I'm personally in favor of including types and having language along the lines of producers SHOULD include type information - because it'll make my life easier when I write the BibDesk parser for microformatted citations. I just felt l should note all the options available. My last sentence might have been misleading. You'd never be able to link to an appropriate copy (because you wouldn't be able to determine with any semblance of confidence what an item actually is) and I'm therefore not sure what the point of this is. I'm not sure I really understand what you're saying here, but if it is that you won't be able to generate a valid OpenURL with no type info, then that's a very good point. If you meant something else, could you elaborate? I think the argument that the formatted (APA, etc) style is enough to denote the type of a resource is misleading - it's enough for a human, even with incomplete information, but for a program, in the (all too common) presence of incomplete info, it's hard to get the type without being told. Actually, is anyone really making that argument? I might be worrying about nothing. I think we shouldn't require types because even a typeless citation is better than not knowing there is a citation there. Does anyone think we shouldn't have types? Certainly it sounds like Bruce doesn't want to display them - but how bad is that, really? And the flip side is - how bad, really, is hiding the types if someone wants to do that? I guess the way I look at it is this: the entire point of formatting a citation in a standardized way is so that another scholar can then go in and know how to find the item again to follow the first person's research. If the second scholar's /browser/ can do this work, the way that it looks on the screen is rather insignificant (much to the chagrin on the MLA and the APA, but they'll probably be happier in the long run). Agreed - wouldn't reference lists be more readable if they didn't need to show the volume number and pages of an article, for instance? Just people, titles and years is all I care to see as long as there's a link to the full item. I've gone on record repeatedly that I don't care if hCite looks like OpenURL as long as it's easy to make something remotely OpenURL from it, but this is a fairly vital part of OpenURL... the very basic notion of knowing what something is. I would recommend that we at least use the basic the journal (journal, article, issue, proceeding, conference, preprint), book (bookitem, book, proceeding, conference, report), dissertation (or thesis), or patent that are currently defined under the San Antonio profile in OpenURL (and it's actually trivial to add other formats if necessary -- yes, that's an open invitation to you, Bruce ;)). No, you don't have to use these labels, but if you want to get the darn thing, choose something that we can map to. -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: one citation microformat use case (Michael McCracken)
I only meant that a citation provides two useful pieces of information: stating that yes, someone else has said this, and where, when, and in what format I found said citation. I'd also like to take a minute to argue with placing the citation styles (MLA, APA and friends) with only an informative link at the end of the citation-examples page. I think the word style here comports too much information for web developers. I would argue that we should dissect these styles in order to document the relevant information in each, from which we can generate our class names. Just as hCard and hCal were built on standards, so should hCite be built on established, implemented standards, i.e. MLA, APA etc. That these formats are on paper and do not have explicit mark-up is a non-issue: they have implicit mark-up that we can document. We still had to decide whether to call it fn or full-name, right? This is merely a logical extension. I think this is a worthwhile undertaking. Other thoughts? If so I'll volunteer to take on MLA. -- Ryan Cannon Interactive Developer MSI Student, School of Information University of Michigan http://RyanCannon.com/ On 14 Feb 2006, at 5:32 AM, Michael McCracken wrote: You lost me with your discussion of comporting validity - are you referring to just expressing author/location information for the cited work or something more elaborate than what is currently done with citations? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
On 11/13/06, Brian Suda [EMAIL PROTECTED] wrote: 1) The term Pages i think that actually has two meanings which i have confused in the implied schema. The first being This book is 45 pages long which is metadata about the book, and is in the realm of media-info microformat. Then there is this sites pages 43-45 meaning a location. So now we need figure out what we are to do? Pages to indicate the length of a book should be beyond scope. It's not relevant to citations. Beyond that, there are two kinds of locators of this sort: 1) to indicate the place of an item within a larger container 2) so-called point locators which indicate specific pages/paragraphs/etc. within a cited item; typically included in citations (Doe, 1999, p12). For the best balance of simplicity and generality, I'd suggest just pages. Don't worry about start and end because, as you noted, pages can be discontinuous. 2) one of the manditory properties across several different citation formats is TYPE. Is this a Book, Journal entry, Thesis, Video, etc. Usually and enumerated list of values. The issue is that EVERYONE does it differently... And from my own experience, this is not at all easy to do. I've been talking about this issue of late with the Zotero guys, because every week people keep asking for more types on their forums. But if you just keep adding them without some kind of design logic -- and a mapping to the formatting system and its type logic -- you end up with a mess. So, I do think a list is important, but I suggest that this not be the focus for hCite 1.0, and maybe see if we can find some agreement as a separate effort. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
In message [EMAIL PROTECTED], Bruce D'Arcus [EMAIL PROTECTED] writes A page in that context is simply not the same as a page in a full bibliographic entry. You'd have to call it cited-pages or some such. It seems to me that the following properties might be recorded: the total number of pages in a publication (be that a book, magazine, thesis, etc.) the total number of pages in a publication series (be that a set of books, a year's worth of magazines, etc.) the total number of pages in a cited article, book-chapter, or other section of a publication the unique single page of a cited section the start page of a cited section the end page of a cited section the page run (e.g. 3-4, 6, 8) of a cited section the unique single page of a quotation the start page of a quotation the end page of a quotation the page run (e.g. 3-4, 6, 8) of a quotation At the very least, if we include some, but not all. of those in hCite, we should name them in such a way as to make it possible, preferably simple, to include the others in future. Presumably, existing citation standards have already addressed the issues of page number categories? -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Easy book citations
I think one of the stumbling blocks we're having here is trying to figure out what we're really using citations for. 1) There's obviously a group that wants this data to be used with bibliographic management software 2) There's a group that wants these citations to be able to link to fulltext/print/etc. for any person's library 3) There's a group (I think?) that wants to be able to display properly formatted citations (or, at least more properly). Are we leaving a scenario out? #3 seems the most complicated. If the goals of #1 are met, then #2 will most likely be met, as well (although not necessarily the reverse). Does this seem accurate? -Ross. On 7/30/06, Edward Summers [EMAIL PROTECTED] wrote: On Jul 30, 2006, at 2:08 PM, Tantek Çelik wrote: What if we set a goal for hCite 0.1 of August 30? Is that reasonable? If Brian Suda has the spare cycles I think this is an excellent idea. The citation effort has gone on for a long time, so Simon's questions are most welcome. //Ed___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [citation]: Brian's outstanding issues 2:
On 9/25/06, Michael McCracken [EMAIL PROTECTED] wrote: I do agree that using an element with type class instead of a huge number of type classes is the way to go here, to avoid class namespace pollution. I actually don't like using the separate element, in part because this information is usally not displayed, but rather used for processing (styling and conversion). The type does matter for display, in other words, but in more subtle ways that have the user see book. Before we settle this, can we go over the technical arguments against using classes? I know, for example, that Tantek once said it's not generally good practice to double up classes (hcite book) but I'd like some explanation about why. But I will say that in either case, one must allow for extensions. I've worked on this for a long time, and defining a fixed list of types that is anything but arbitrary is pretty much impossible. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
On 11/13/06, Chris Messina [EMAIL PROTECTED] wrote: In terms of type... How important is that designation? If you have an open-ended list, isn't that similar to a tag or is there real consequence to its type-designation? It's very important for conversion into some formats (BibTeX, RIS, etc.), and sort of important too for formatting in the sense the there are different conventions (rules) for formatting different kinds of references. Note, though, that as someone who designed both a citation style language and code to format citations, I think sometimes people get too distracted by type. Often times, formatting rules are more about other details than type. For example, someone on the Zotero forums recently claimed edited books get formatted differently than books. Well, not really. What gets formatted differently are editors and authors (the former gets a role label added to it). Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
On 11/13/06, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Bruce D'Arcus [EMAIL PROTECTED] writes Pages to indicate the length of a book should be beyond scope. It's not relevant to citations. I disagree, not least because people often cite a whole book, rather than part of it. Which is exactly why the length of the book is irrelevant. The only time you include pages in a citation is if you are referring to a section within a book (typically a chapter), and the purpose there is simply to help you find it. Page count does nothing to help you with that, and for that reason they are never included in citations in my experience. Page count is only relevant to publishers and book stores (maybe). For the best balance of simplicity and generality, I'd suggest just pages. Don't worry about start and end because, as you noted, pages can be discontinuous. But what about inter-operability with other standards? Which ones? There is no standard way to do this; some use start/end and others a single property. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
On 11/13/06, Andy Mabbett [EMAIL PROTECTED] wrote: But citation uFs are being recommended for more than pure academic citations - in resumes, for example, where the page count is likely to be far more relevant. I seriously doubt it. I certainly wouldn't include it (and don't) in my CV. Page count is only relevant to publishers and book stores (maybe). That's an assertion for which you can provide no evidence. Likewise. Look, I don't have time to track down a heap of evidence for you; either accept my argument, or don't. ... some use start/end and others a single property. So why not allow both to be marked up? I'm really not that invested in this. I gave my suggestion for the best solution. You're entitled to your's. Either way is more-or-less fine by me. But I do feel strongly that page count is beyond scope. Do we want to then include ways to encode the length of a CD or a DVD film or an HTML document? I think not, particularly when there are more important issues to worry about. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
On Nov 13, 2006, at 2:30 PM, Andy Mabbett wrote: In that case, the start page will surely be the most relevant? Yes. On Nov 13, 2006, at 3:11 PM, Bruce D'Arcus wrote: But I do feel strongly that page count is beyond scope. I agree. It doesn't seem to help any of the use cases identified in the wiki: http://microformats.org/wiki/citation-brainstorming#Use_Cases I'm sure there are contexts in which page count would be helpful, but those seem to relate more to the media-info problem of distinguishing between multiple means of publishing the same content: http://microformats.org/wiki/media-info-brainstorming#The_Problem As always, I look forward to clear explanations of where I might be mistaken. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] [hCite] dates
Michael McCracken wrote: Looking at the examples on citation-examples, I find the following frequencies of marking up a date: publication date: 21 date accessed: 3 date copyrighted: 1 (from OCLC worldcat online) Actually, date accessed has at least three more examples: umich ning Google However, they use retrieved rather than accessed, although it is the same meaning. I just added date-accessed to the working straw schema. Great. Certainly all three are useful, but can we find more examples for the last two? I'd be more comfortable having a 'date copyrighted' field in the uf if there was more than one real-world example on the wiki. What would be the right way to make the retrieved and accessed labels as synonymous? -j -- Joe Andrieu [EMAIL PROTECTED] +1 (805) 705-8651 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Easy book citations
Ross, I think one of the stumbling blocks we're having here is trying to figure out what we're really using citations for. ... Are we leaving a scenario out? I have a lot of interest shown by Australian government developers - basically every one I mention ufs to independently says a format for citations would be great. What they need is for is that any time a government publication refers to any other publication (a site, a book, a pamphlet on immunisation, a poster on healthy diets, whatever) they have to cite it. But of course there is no citation format. I actually am planning a developer day in the next month or so for government web developers to introduce the ideas and take a good long look at hCite from the perspective of the uf principles. I actually think a reasonably minimal set of properties would suffice for their needs, but hope to find out first hand soon. BTW, any Australian, particularly Canberra based (I'm in Sydney but the interest is federal government developers) people, but really anyone keen to meetup in either place and or chat more on this, please drop me a line john #3 seems the most complicated. If the goals of #1 are met, then #2 will most likely be met, as well (although not necessarily the reverse). Does this seem accurate? -Ross. On 7/30/06, Edward Summers [EMAIL PROTECTED] wrote: On Jul 30, 2006, at 2:08 PM, Tantek Çelik wrote: What if we set a goal for hCite 0.1 of August 30? Is that reasonable? If Brian Suda has the spare cycles I think this is an excellent idea. The citation effort has gone on for a long time, so Simon's questions are most welcome. //Ed___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss John Allsopp style master :: css editor :: http://westciv.com/style_master blog :: dog or higher :: http://blogs.westciv.com/dog_or_higher WebPatterns :: http://webpatterns.org Web Directions Conference :: Sydney September 28-29 :: http://wd06.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: Microformats for scientific papers
On 19 Feb 2006, at 15:54, Ryan Cannon wrote: I like your use of space-separated class names (e.g. citation reference book), but you do have a little bit of redundancy: - abbr implies an abbreviation, so class=journal-title-abbr could just be journal-title That's true, but it's going to be easier for parsers to use the class name to differentiate rather than having to look at the node name as well, so the redundancy might be worthwhile. - li id=ref16a name=ref16 is redundant and may be (not sure) illegal. THe (X)HTML validator doesn't seem to complain, so I think it's ok. The thing is, the li surrounds the citation, so needs an identifier, but there also needs to be an anchor link in the page. I think you can ignore the internal anchor links as far as semantics go: they're only really useful for page navigation, as they don't wrap anything useful. I also question the extensive use of IDs in general. Using ID fields is extremely limiting. How, for example, could one page contain multiple articles, or sections of an article, or only article metadata (such as an abstract list), if these fields require IDs? That's a very good point. I was thinking that I could use ids for sections that commonly only appeared once per article, like abstracts, introduction, bibliography, etc, but you're right, with more than one article on a page that won't work. I guess it'll have to be classes throughout. It seems to me that the main part of getting a scholarly (not just scientific) article microformat would be hCite/citation microformat, and a metadata format (possibly related to Dublin Core??). There is more than that, particularly when you want to include the actual data, but yes, the main parts so far are a) metadata, b) citations and c) common article sections (ie the structure of the paper itself). alf. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [citation]: Brian's outstanding issues 3: nesting
First, a URL for the wiki page you are referring to would be helpful ;-) On 9/25/06, Michael McCracken [EMAIL PROTECTED] wrote: option 1: requires class names for every reference type. I don't like this option either. option 2: uses type class, but makes it confusing IMO - what if you want to include more data about the containing reference than just one element? Does the type continue to influence sibling elements until another type element cancels it out? Can't comment on the above since I don't know the context. I have another option that might work: option 3: nest ufs. I've used this a few times in examples without anyone commenting on it. Is this OK? What are the pros/cons? I have parsed HTML using a DOM traversal before, and this seems like it'd be reasonably easy to parse. It's also a little easier to write and more obvious than #2, IMO, since it's clear that the elements under the container span are all referring to the item that's of type book... span class=citationspan class=typechapter/span: span class=titlestuff/span span class=citation containerspan class=typebook/span span class=titleA collection of stuff/span I thnk that's fine, notwithstanding my other quetion about the type span (which seems even more funky in this case). Also, citation could probably be hcite? Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
differentiating microformats (was Re: RE: Re: RE: [uf-discuss] [citation] url field )
Mike, can you explain what you mean in the context of the citation format? I haven't been following many of the other threads on this list this week, so I don't know what you're referring to. Thanks! -mike On 12/7/06, Mike Schinkel [EMAIL PROTECTED] wrote: Ironically, this sounds like another real-world (i.e. not hypothetical) example of the need to provide a way to differentiate microformats. -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael McCracken Sent: Thursday, December 07, 2006 6:05 PM To: Microformats Discuss Subject: Re: Re: RE: [uf-discuss] [citation] url field This seems to have been buried - so again, to anyone interested in hCite: I want to define a new field URL to denote an http URL that points to the location of a copy of the cited work. URIs that encode an identifier of the work can be combined with this field, but do not need to be. I understand that the name URL may overlap a bit with URI, and something like downloadlink, etc. might be more direct, but I argue that URL is the better choice because it is the most common name already in use in our examples from the web. Can we discuss this revised version of the proposal (or just vote on it?) Thanks, -mike ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation: next steps?
Hello Mike, thanks for bringing this up. I spent a good portion of the weekend looking at my earlier straw proposal. I started to create an XMDP file and took the examples listed on the wiki and attempted to mark them-up with the citation microformat. This would help to find any deficiencies. The 3 main points i came across so far are: 1) IDENTIFIERS 2) FORMAT TYPES 3) NESTING 1) In hCard/hCalendar there is a UID field. Added with URL it makes for a great unique identifier. There are loads of other identifers besides URL, ISBN, LOC call number, SKU, ISSN, etc. Many of these are unique in their domain, but not globally unique. So how to they get marked-up? Much like the hCard TEL/ADR properties, we can use something like: div class=uidspan class=typeISBN/span: span class=value123456/span/div This makes the encoding the most extensible... if we start use class=isbn then it is an enumerated list, with class=type it is open ended. 2) I keep mis-using format, format is the medium - hardback, softback. The TYPE (there probably is a better word - container?) is book, article, conference, manifesto, etc. Much like the identifers we can make an enumerated list of values, class=book, class=article, but that boxes us in, whereas something like: span class=typearticle/span leaves things more open. 3) Nesting citation data in a citation. The ability to nest the same microformat inside itself is something that other microformats don't explicitly handle. The two options are: i) Using class=book div class=hcite div class=book span class=fnBook Title/span div class=chapter span class=fnChapter Title/span /div /div /div This makes things easy to nest and to figure out exactly what is associated with what, but the downside is that we have enumerated lists of values for the class properties. ii) using the TYPE for book div class=hcite div class=typebook/div span class=fnBook Title/span div class=typechapter/div span class=fnChapter Title/span /div now the class=fn is not nested inside the class=book or class=chapter so there would have to be some other mechanism to associate the data with the type. This is just a brief summary of the outstanding issues. I have been quite busy with other things, and i'm not sure exactly how or where to proceed? I have a feeling the citation discussion is pretty heavy and i don't want to waste people's time with all the back and forth messages on the mailing list - it is high traffic enough already... the wiki is nice, but not everyone keeps a close eye on it... IRC is another option. We've done 'meet-ups' in the past and they worked fairly well? so i'll leave it up to others on where/how we should proceed. maybe like the REST mailing list we need to spin off a temporary citations mailing list? (although that means YAML, Yet Another Mailing List) I am still working on exactly WHAT we are proceeding on. I'll be offline for the next few days due to traveling, so a deadline of the 30th is probably not realistic. I am certainly open to suggestions. -brian On 8/29/06, Michael McCracken [EMAIL PROTECTED] wrote: Hi, aside from adding a few good examples of existing formats, it looks like there hasn't been any movement toward the Aug 30 deadline for hCite 0.1. Should we reschedule the goal? Also, what is the immediate next step on the path to a recommendation? Do we need to clarify the existing research on the wiki? Is anyone waiting for an answer or agreement before moving forward? Thanks, -mike -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] [citation] Call for scope check (was Re: Citation: next steps?)
Why aren't we looking for an established format to fulfill our 80/20
requirement and become a
good 1:1 scope?
BibTex does authors like this,
@article {
Author = {Vicente, Kim J. and Rasmussen, Jens}
...
}
While EndNote does it like this:
record
contributors
authors
authorVicente, Kim J./author
authorRasmussen, Jens/author
/authors
/contributors
...
/record
BibDesk[1] also exports the following:
dd class=Pub
span class=AuthorVicente, Kim J. and Rasmussen, Jensspan
...
/dd
Perhaps instead of wheel reinvention, we should look to one of these
well-used citation formats.
Is there any reason why neither BibTex nor EndNote fields are listed
in the citation-examples
page of the wiki? They seem the closest thing to what we're looking
for, i.e. BibTex could be to
hCite what vCard is to hCard. Blithely creating our own format seems
reckless and doomed to
obscurity.
[1]: http://bibdesk.sourceforge.net/
--
Ryan Cannon
Interactive Developer
MSI Student, School of Information
University of Michigan
http://RyanCannon.com
On Sep 22, 2006, at 3:00 PM, Michael McCracken
[EMAIL PROTECTED] wrote:
On 9/22/06, Bruce D'Arcus [EMAIL PROTECTED] wrote:
On 9/22/06, Michael McCracken [EMAIL PROTECTED] wrote:
That is the most straightforward way, yes. The problem I have
with it
is the repeated role term will be displayed for every
contributor, and
will likely end up being more hidden data.
No, I'm saying have two main terms: creator and contributor.
Only add a role when it actually needs to be displayed (which is not
the case for an author). Using creator for author is fine.
So you're saying that for the common case where creator is clear
enough, it'd look like this:
span class=citation
span class=creator vcardauthor1/span
span class=creator vcardauthor2/span
span class=title article title/span
...
/span
And then only use 'role' where necessary to clear things up?
I like that, and now I see where you said it earlier, but I missed
it then.
This sounds like a good solution. What does everyone else think?
Also, what's the next issue to resolve before we can put out a draft?
-mike
--
Michael McCracken
UCSD CSE PhD Candidate
research: http://www.cse.ucsd.edu/~mmccrack/
misc: http://michael-mccracken.net/wp/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Easy book citations
On Sun, 30 Jul 2006, Bruce D'Arcus wrote: On 7/30/06, Fred Stutzman [EMAIL PROTECTED] wrote: Well, of course it isn't the overwhelmingly dominant bibliographic/citation format It's not even close. If you ask 100 people in my field about BibTeX, my guess is at least 90 of them of them won't even know what you're talking about. Of course, a lot of them probbaly manually author their bibliographies (!), but still RIS and Endnote are perhaps even more widely supported formats for personal reference management. Both of those formats are based on a more general three level model. I think this misses the point. At the consumer level, the citation format should be transaprent - they should not know what type of citaiton they are authoring (do most people understand the RefWorks citiation format? No). The key is that many systems - web, desktop and machine-to-machine have adopted this format. It will be much easier for CiteULike, CiteSeer, Connotea etc to implement with what they already have. Of course, we can dream up blue-sky scenarios on how to make a better citation format. I'm sure we can do better. But if we do, we miss the boat and lose the collective value of all the software that would natively support the format. Regardless of the end result, you will need software to convert from legacy formats into and out of hCite. There is no way around that. I've done enough work on this stuff -- and worked with other developers; people like Chris Putnam on his excellent bibutils converion tools -- to tell you that it's pretty easy to design a a good format that will be easy to use, extend, and process. Nothing blue sky about it. And it won't be hard to convert into and out of BibTeX either (except, of course, where BibTeX's limited data structure gets in the way). Indeed, it is easy to design a new standard. It is not easy to get people to adopt that new standard. But if you follow the BibTeX way strictly (where all properties are single values) you will end up with an hCite tha is liimited, and akward to extend. Every time someone needs to represent a different kind of resource, they'll have to go through some complicated community consensus process just to get their new ttitle, etc. propreties authorized. There is no requirement to follow bibtex strictly. It seems very reasonable to start with an existing standard and iterate upon it. There's no reason why we shouldn't be making it better. There really is a better way. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- Fred Stutzman claimID.com 919-260-8508 AIM: chimprawk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation format straw proposal on the wiki
On 3/30/06, Tim White [EMAIL PROTECTED] wrote: 2) Adapted to current behaviors and usage patterns. Microformats are suppose to be modeled on what people are currently doing (80/20) on the web. I think of it in terms of the Everyman/woman. Capturing metadata isn't what is happening by the 80. Look at the examples collected on the wiki, very little metadata if any. (http://microformats.org/wiki/citation-examples -- look to the Implied Schema section) Earlier in this thread I stated that many of these examples are exactly the opposite of what we're trying to do -- they violate the useful and precise distinction indicated on the cite-brainstorming page between content at hand and what's referenced by but external to what's at hand in that they represent the former, not the latter. I'll repeat my offer to augment or replace those with examples of cited references from a variety of extremely heavily-used-worldwide online publications. You will find even less markup there, which makes your point much stronger yet much less convincing. The library community (such as it is... there are about three of us in here, so far as I can tell) isn't after something to replace the existing standards. We simply want to help ensure that the insight professed by this statement: Better to leverage all the hard work that others have done before you, than to go off as a solo cowboy inventor, and waste time repeating all their mistakes. ...needn't be proven accurate yet again here. And, to try to ensure that hCite can usefully interact with the infrastructure we've built. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Easy book citations
On 7/31/06, Ross Singer [EMAIL PROTECTED] wrote: I think one of the stumbling blocks we're having here is trying to figure out what we're really using citations for. 1) There's obviously a group that wants this data to be used with bibliographic management software 2) There's a group that wants these citations to be able to link to fulltext/print/etc. for any person's library 3) There's a group (I think?) that wants to be able to display properly formatted citations (or, at least more properly). Are we leaving a scenario out? #3 seems the most complicated. If the goals of #1 are met, then #2 will most likely be met, as well (although not necessarily the reverse). Does this seem accurate? On 3, I've been working on cracking the formatting nut for the past couple years, and am just about done [1]. It is indeed quite difficult, but I mostly see it as distantly related to hCite. But I see citation metadata as a cycle. I want ulitmately to be able to output good uF metadata such that users can: - view a nicely formatted document in their browser, complete with proper citations - click some button and go to the original article or book - click some other thingy and import citations into my browser-based reference database (coming real soon, GPL licensed!), or copy-and paste the citation content directly into Word or OpenOffice - be able to use that data to create other documents with citations So yeah, a good data format supports 3, though is not so much its own requirement. Bruce [1] http://netapps.muohio.edu/blogs/darcusb/darcusb/archives/2006/07/29/csl-progress ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
In message [EMAIL PROTECTED], Bruce D'Arcus [EMAIL PROTECTED] writes On 11/13/06, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Bruce D'Arcus [EMAIL PROTECTED] writes Pages to indicate the length of a book should be beyond scope. It's not relevant to citations. I disagree, not least because people often cite a whole book, rather than part of it. Which is exactly why the length of the book is irrelevant. No it isn't. Note not least. The only time you include pages in a citation is if you are referring to a section within a book (typically a chapter), and the purpose there is simply to help you find it. Page count does nothing to help you with that, and for that reason they are never included in citations in my experience. But citation uFs are being recommended for more than pure academic citations - in resumes, for example, where the page count is likely to be far more relevant. Page count is only relevant to publishers and book stores (maybe). That's an assertion for which you can provide no evidence. Don't worry about start and end because, as you noted, pages can be discontinuous. But what about inter-operability with other standards? Which ones? There is no standard way to do this; Hence my deliberate use of the plural. some use start/end and others a single property. So why not allow both to be marked up? -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite elevator pitch and my bibliography generator
On 3/23/07, Paul Wilkins [EMAIL PROTECTED] wrote: Henri Sivonen wrote: On Mar 10, 2007, at 23:10, Paul Wilkins wrote: You are using the BibTex format, which is covered in the citation formats http://microformats.org/wiki/citation-formats Sure, but considering that I share my .bib, should I expect people to want to scrape my (X)HTML-formatted bibliography? --- YES! if you ONLY offer the reference as a .bib file then you are locking people into having to use BibTeX. You can certainly offer the .bib file, but by marking-up the XHTML, then people can extract the semantics and create CSV, Dublin Core RDF, TXT, or other formats for free. You do NOT have to have 400 small icons saying download as: ... If the .bib is used as the lone source for the XHTML, I suspect it would be easier to scrape the .bib file. --- What i tend to do for things like vCards and iCalendars is to create a static link to a .vcf file and then with Mod_rewrite or other tools make that a Link to a service that converts the HTML to a .vcf The same can be done with a .bib file. That way when you update the HTML page, you do NOT have to update several other files as well since they are dynamically created from the single SOURCE XHTML file. -brian -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite nesting (citation/bibliography/collection/collections)
Aloha, Take for example CiteSeer[1], a collection of the metadata for 767,558 documents. An example metadata page[2] has a number of bibliographies embedded in it[3], including: [A] Documents which cite the current document [B] Documents which share citations with the current document [C] Documents which are similar based on textual content [D] Other documents which are being cited by those citing this current document (A) [E] Citations from the current document, and [F] Documents from the same site as the current document Note that these metadata pages also have ratings (1-5 stars), summaries, bibTeX entries, and citation statistics. On the ACM website[4], a given article[5] has a link to 'find similar articles'[6], which is in essence an annotated bibliography. It seems that rel (rev being deprecated[7]), with a bit of semantics, could distinguish the various kinds and instances of citation in a given document. There seem to be the following: [i] works cited [ii] works citing [iii] works sharing citation [iv] works otherwise akin (non-reference-based) In the case of [D] above, we have a nested relationship of [ii]:[i], namely the works cited from those works citing this one. References [1] http://citeseer.ist.psu.edu/cs [2] http://citeseer.ist.psu.edu/darken98navigating.html [3] http://bizseer.ist.psu.edu/help/SMEALSearch-help-documentPage.html [4] http://www.acm.org/ [5] http://portal.acm.org/citation.cfm?id=1284621.1284635 [6] http://tinyurl.com/2fhax5 [7] http://microformats.org/wiki/rev#Should_rev_even_be_used -- Sincerely, Jeff McNeill http://jeffmcneill.com/ On 10/14/07, Benjamin Hawkes-Lewis [EMAIL PROTECTED] wrote: Jeff McNeill wrote: Question: is there a set of semantic containers that could identify a bibliography within a given document, as well as a collection of bibliographies across documents? What's wrong with... ul class=bibliography/a link href=foobar rel=bibliography (from each document in the collection) -- Benjamin Hawkes-Lewis ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Re: [uf-discuss] Easy book citations
I do have some spare cycles (not many), but i'm always up for a challenge, August 30 is acceptable. p class=shameless-plug I have to prep some for my talk at EuroOSCON in september, hopefully i can add some citation stuff in there as well. If anyone else will be attended feel free to say hello in person. /p p class=shameless-plug The other thing that is keeping very busy is that i am putting some final touches on a Introduction to Microformats eBook for O'Reilly, which is due in a few weeks. It is part of their shortcuts series and i'll post a link once it is available. /p A few of the other things to clarify and point out from where we left off and to bring people up to speed. 1) The list of properties available in the straw proposal may look long and unweildy, but that is just a FRACTION of what was available. It may not seem like we started simple but if you knew what is out there, you'd realise that we did! The way we arrived at those properties are as follows: We examined several of the most popular formats, and took the UNION of their common terms. We then examined examples in the wild and then took a UNION of those terms and the common terms of the formats to arrive at the short list in the strawman. 2) Much like hCard, you don't have to use the FULL microformat. hCard has options for ORG, ADR, etc. If you wanted to just represent a structured name, there is no need to create a microformat, just use the parts of hCard you need. This citation microformat will be similar. If you want to JUST have a book title, then this format will sufice, it is just like any of the other microformats, beyond the required properties, everything is optional! 3) One of the other things we wanted to look out for was the emergence of the media-info format. There has been some movement on that. We wanted to be sure that the way a citation describes a book/CD/DVD is not incompatable to that of a media-info format. Arguing end-user formats, i think, it is moot. Once we have a solid citation microformat that covers the 80/20 of the common terms within the citation formats AND citations in the wild, you will be able to transform that HTML into BibTeX, COiNS, OpenURL, MS Word ODF Citation, CSV, or any that pop-up in the future - you can even style it in Plain-Text as MLA, Chicago Style, or any other. I'll do some homework and get caught-up with all the developments since our last major discussion. -brian On 7/30/06, Edward Summers [EMAIL PROTECTED] wrote: On Jul 30, 2006, at 2:08 PM, Tantek Çelik wrote: What if we set a goal for hCite 0.1 of August 30? Is that reasonable? If Brian Suda has the spare cycles I think this is an excellent idea. The citation effort has gone on for a long time, so Simon's questions are most welcome. //Ed___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] citation: another example of practice in the wild
On 8/16/06, Michael McCracken [EMAIL PROTECTED] wrote: Bruce wrote: Though there was some recent hints that things are about to start moving again. That's encouraging - what hints were you referring to? Anything in public we can echo here? Yeah, recent list discussion; Tantek throwing down the gauntlet for a 0.1 August 30 release, Brian saying that sounded reasonable, etc. I really think we need an hDC and hDCQ. It's really not the microformat tradition, it seems to me, to invent full standalone formats. I'm afraid I'm only slightly familiar with how DC elements are being used. It seems like they're only being used (in HTML) now to describe whole pages, not parts of pages. I just read the DCQ page [1] about using DC terms in meta and link elements in the HTML head element - that's where I'm getting this from. Are you suggesting a new design pattern for using dublin core elements and qualifiers in all microformats? Or a specific microformat to cover some particular cases when you'd use DC? The former. DC and DCQ cover generic stuff: contributors, dates, titles, subjects, relations. Those are important in lots of contexts beyond citaitons. It makes more sense to me that hCite would use that, and that other formats could too, than that we'd define it all in hCite. FWIW, here's the demo I prepared for the ODF group to show namepsace and vocabularly mxing, and example of the relational character of citation data.. It's RDF, but I'm sure you can imagine a mapping to microformats. rdf:RDF xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#; xmlns:dc=http://purl.org/dc/elements/1.1/; xmlns:meta=urn:oasis:names:tc:opendocument:xmlns:meta:1.0 xmlns:b=http://purl.org/net/biblio#; xmlns:v=http://nwalsh.com/rdf/vCard#; xmlns:dcq=http://purl.org/dc/terms/; xmlns:foo=http://foo.net/; b:Reference rdf:about=x b:author v:VCard v:n v:Name v:given-nameJane/v:given-name v:family-nameDoe/v:family-name /v:Name /v:n /v:VCard /b:author !-- use dc:type for typing, with controlled URI list -- dc:type rdf:resource=http://purl.org/net/biblio#Article/ dc:titleSome Title/dc:title dcq:isPartOf b:Collection dc:titleJournal Title/dc:title dc:type rdf:resource=http://purl.org/net/biblio#Journal/ /b:Collection /dcq:isPartOf b:volume23/b:volume b:issue2/b:issue b:pages123-165/b:pages /b:Reference b:Reference rdf:about=urn:isbn:0226738892 b:author v:VCard v:n v:Name v:given-nameCarl/v:given-name v:family-nameSchmidt/v:family-name /v:Name /v:n /v:VCard /b:author dc:title xml:lang=enPolitical Theology: Four Chapters on the Concept of Sovereignty/dc:title dc:date2005/dc:date dc:type rdf:resource=http://purl.org/net/biblio#Book/ dc:publisher v:VCard v:fnUniversity of Chicago Press/v:fn v:adr v:Adr v:localityChicago/v:locality /v:Adr /v:adr /v:VCard /dc:publisher dcq:isVersionOf b:Reference dc:title xml:lang=dePolitische Theologie: Vier Kapital zur Lehre von der Souveranitat/dc:title dc:publisher v:VCard v:fnDuncker Humbolt/v:fn v:adr v:Adr v:localityBerlin/v:locality /v:Adr /v:adr /v:VCard /dc:publisher dc:date1922/dc:date /b:Reference /dcq:isVersionOf /b:Reference /rdf:RDF Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation Straw Proposal II
Brian, this is quite impressive. I particularly like the use of hCard in this context (although I think it's critical that we use more granular n attributes -- there are just too many ways to mark up a citation). Going into your unresolved items -- I see URL being pretty darned important. It's going to be difficult, otherwise, to differentiate between a link to the cited resource or some other generic link that happens to fall inside the hCite block. IMG -- Off the top of my head, I don't see much need for this... What was the inspiration for this? Author/Editor/Translator should be a priority. I realize this is more important in the computer vs. human continuum, but it doesn't seem /that/ difficult to make it an easy win for both camps. Does License generally appear in citations? Granted, I don't find myself formally citing things very often, but I haven't really run across this. isPartOf seems pretty important, as well (or, at least it seems like it would come up quickly)... What do people think here? Would it refer to another hCite? Thanks for putting this together, Brian. -Ross. On 4/29/06, Brian Suda [EMAIL PROTECTED] wrote: I have spent some time reviewing the examples and the formats on the wiki. Here is the list of the implied schemas. These are the common fields amongst the examples. I then looked at the cross over between the real-world examples and the formats and have created a straw proposal from that. At the moment it is pretty strict, i only included VERY common properties - it is easier to make additions than subtractions - so if there is a property that is NOT in the straw proposal please speak-up. implied schema (examples) + publisher + language + description + title + creator + volume + issue + page + edition + identifier + tags + format + date published + copyright - audience implied schema (formats) + publisher + language + description + title + creator + volume + pages + edition + issue + identifier + tags + format + date published + date copyrighted - subtitle - image - excerpt - index terms - series title - publication - journal - part (1 of X) UNION of the two schemas + (PLUS) means common properties - (MINUS) means unique to the schema Brian's Straw format ul class=bibliography li class=citation xml:lang=en-gb !-- publisher data as hCard-- div class=publisher vcard span class=fn orgABC Publishing Co./span span class=country-nameUnited Kingdom/span ... /div !-- author(s) data as hCard -- div class=creator vcard span class=fnJohn Doe/span ... /div !-- location data -- span class=titleFoobar!/span span class=descriptionWorld Class Book about foobar/span span class=volume1/span span class=issue1/span span class=edition1/span span class=pages1-10/span span class=formatarticle/span !-- differed to the UID debate -- span class=identifier12345678/span !-- keywords -- span class=keywordfoo/span span class=keywordbar/span !-- date properties -- Published abbr class=dtpublished title=20060101January 1st 1006/abbr Copyright abbr class=copyright title=200601012006/abbr /li ... /ul p class=citationHave you read span class=titleabbr title=book class=formatFoo Bar/abbr/span? It was written by span class=author vcardspan class=fnJohn Doe/span/span. It only came out a abbr class=dtpublished title=20060101few months ago/abbr/p FIELDS THAT MIGHT BE IMPORTANT, BUT WERE NOT IN BOTH IMPLIED SCHEMAS - URL (this is probably do to several examples of older citation formats not having URLs, is this important or can identifier handle this property?) - IMAGE (not sure what this would be an image of, but HTML has img element, so it could be of use? Does it help to cite something?) - AUTHOR, EDITOR, TRANSLATOR, etc. At the moment these are all lumped into 'creator' which will need to be expanded as appropriate. Probably (author | editor ) - ABSTRACT, NOTES, EXCEPT, etc. At the moment these are lumped into 'description' - Difference between COPYRIGHT and LICENSE, currently citation copyright is a date-time, license would be the TYPE. License is NOT accounted for. - IsPartOf is another property that has been discussed which is not represented. - Other properties like 'audience' are in some formats (DC) but were not common enough to be considered in the format schema. Overall this straw format is on the minimal side, so lets review this and see what needs to be addressed and how to do so. i have added the straw proposal to the wiki[1], so feel free to make changes
Re: Re: [uf-discuss] Citation Microformat: LazyWeb for BibTeXperts
On 10/6/06, Brian Suda [EMAIL PROTECTED] wrote: On 10/6/06, Bruce D'Arcus [EMAIL PROTECTED] wrote: Why? Seems quite awkward to me to call a title a fn. --- part of this goes back to no-namespacing in Microformats. ... OK, I see. That wall I mentioned. ... As for KEY, that is something that is NOT currently in the implied schema (again the examples might have been more PRODUCT pages rather than a bibliographic list of citations). KEY could be handled as an ID (most sites have some sort of hyperlink back to the internal reference) or as it's own class=key, but that sounds alot like IDENTIFIERS to me, and then we are back to the idea of span class=identifier span class=typeKEY/span: span class=valueSU06/span/span. Then does KEY need to be GLOBALLY unique (sounds like a URI) or just locally unique in the .BIB file (because that could be generated by the Web Service)? Yes, there is no way that the conventions of BibTeX -- conventions which preceded the web-- ought to be in any way privileged in hCite. Key is one of these. They are indeed just identifiers. Within BibTeX, keys only need to be locally unique. For reference, I use URIs to achieve the same thing in my citations, but in more robust ways. One thing I'll repeat is that not all data needs to be displayed. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: RE: [uf-discuss] Citation Microformat: LazyWeb for BibTeXperts
On 10/6/06, Brian Suda [EMAIL PROTECTED] wrote: On 10/6/06, Joe Andrieu [EMAIL PROTECTED] wrote: I'm assuming that means it isn't included in what you've done so far. --- correct. From the examples online[1] most (if any) did not have a dateAccessed. [well one did CiteProc_XHTML_Output[2], which doesn't fall into the 80/20]. I'm not against exploring dateAccessed, there might be ways to extract an access date without actually declaring it explicitly. Run this search on Google: site:wikipedia.org accessed on It's not very precise (it probably misses some stuff), but I get over 6,800 hits; from one site! Fair to say it's pretty real world. If you are looking for the DATETIME that you viewed the article, then that could be added by the transforming application (this might be a bad idea?) and/or use the timestamp that is sent in HTTP Headers (Last-Modified date - again, maybe a bad idea?) All an access date does it authenticate a URL; it says the URL was valid on this date. URLs change, so citations REQUIRE access dates. I have never seen an exception to this rule. Whether we call it dtvalid or dtaccessed doesn't matter that much. BTW, worth looking at Zotero, which has just gone live: http://zotero.org They'll be supporting hCite once it's done. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
In message [EMAIL PROTECTED], Bruce D'Arcus [EMAIL PROTECTED] writes But citation uFs are being recommended for more than pure academic citations - in resumes, for example, where the page count is likely to be far more relevant. I seriously doubt it. That's your prerogative; but foolish. Particularly as it was mentioned just today: http://microformats.org/discuss/mail/microformats-discuss/2006-November/007103.html I certainly wouldn't include it (and don't) in my CV. And do you also think that everyone does as you do? Page count is only relevant to publishers and book stores (maybe). That's an assertion for which you can provide no evidence. Likewise. Look, I don't have time to track down a heap of evidence for you; I didn't say that you hadn't provided evidence; I didn't say that you wouldn't provide evidence; I didn't even ask you to provide evidence. I pointed out that you CANNOT provide evidence. either accept my argument, or don't. It's not an argument, merely an unfounded assertion. -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
'date accessed' in bibtex (was Re: [uf-discuss] hCite progress)
I noticed that 'accessed date' wasn't discussed in the resulting thread here.
As far as I know, it doesn't map to any 'official' field in BibTeX.*
It is perfectly fine to include it as a new field: 'accessed-date' or
something:
@misc{aslbp:2005,
title={A short-lived blog post},
accessed-date= {11/2005},
...}
If I wanted to display it in my citations list using bibtex and the
style files I've used, I'd put it in the 'note' field like this:
note={accessed on 11/2005}.
I'd prefer the 'accessed-date' solution, because it's more meaningful.
-mike
* meaning I'm not aware of any common style files that use it. There
could be plenty that aren't common or I haven't seen...
On 11/13/06, Brian Suda [EMAIL PROTECTED] wrote:
Also, i have wiki-fied several citation examples from a previous
email, with accessed date. I have not updated any implied-schemas to
reflect any changes yet. I haven't outputted the accessed date into
BibTeX, RIS or Dublin Core because i don't know what field they equate
too? Alot of this will get flushed out when we start building examples
and tests.
All input is welcomed.
Thanks,
-brian
--
brian suda
http://suda.co.uk
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
--
Michael McCracken
UCSD CSE PhD Candidate
research: http://www.cse.ucsd.edu/~mmccrack/
misc: http://michael-mccracken.net/wp/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [hCite] dates
On 1/17/07, Joe Andrieu [EMAIL PROTECTED] wrote: Michael McCracken wrote: Looking at the examples on citation-examples, I find the following frequencies of marking up a date: publication date: 21 date accessed: 3 date copyrighted: 1 (from OCLC worldcat online) Actually, date accessed has at least three more examples: umich ning Google Thanks - I thought I'd counted those also, guess I forgot. :) However, they use retrieved rather than accessed, although it is the same meaning. I just added date-accessed to the working straw schema. Great. Certainly all three are useful, but can we find more examples for the last two? I'd be more comfortable having a 'date copyrighted' field in the uf if there was more than one real-world example on the wiki. What would be the right way to make the retrieved and accessed labels as synonymous? I don't fully understand the question? Do you mean to allow using either as a class name? I think just having one in the uf, and if necessary noting that they mean the same thing, should be enough. -mike -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [hcite] date-published
Mike said: From Bruce D'Arcus on the wiki: I've mentioned more than once that date-published is misleadingly specific; too much for real world citations. Consider that many books are published in the year preceding their copyright date, which is in fact the date used for citation. I'd prefer just date and date-accessed as a first cut. --Bruce 3 Feb 2007 I agree - this maps well to current practice in existing formats I know of - they tend to not specify the type of date, instead using fields like month and year. Is anyone against changing 'date-published' to 'date'? -mike I vote for leaving it date-published. It really doesn't matter when consumers get their hands on a published piece, all that matters is when it is (claimed to be) published. So, looking at Mike's example, in Jan. 2007 many magazines have March 2007 dates on them. That should be considered the publication date. Think about five years from now when you go to look up that magazine: what is the date you will cite? March 2007. You may not know (or care) when it actually hit the shelves, and it doesn't matter. ~ Tim tjameswhite.com'http://www.tjameswhite.com;tjameswhite.com Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite elevator pitch and my bibliography generator
On Mar 23, 2007, at 14:22, Paul Wilkins wrote:
Henri Sivonen wrote:
On Mar 10, 2007, at 23:10, Paul Wilkins wrote:
You are using the BibTex format, which is covered in the
citation formats http://microformats.org/wiki/citation-formats
Sure, but considering that I share my .bib, should I expect people
to want to scrape my (X)HTML-formatted bibliography?
If the .bib is used as the lone source for the XHTML, I suspect it
would be easier to scrape the .bib file.
It is the lone source.
The citation microformat is a work in progress at this stage, so
it's not mature enough for programs to extract information from it,
I guess this means that I shouldn't try to support hCite on the
generator side in my thesis considering that the document should
go final on the first week of April.
Even though it goes final then, does that prevent you from later on
adding markup which doesn't affect the text, yet makes it easier
for tools to scrape through the information?
There's no technical barrier to updating the file, but as a matter of
archival principle, it seems wrong to tamper with the dated file
later on. Tampering with it could lower the confidence of readers in
the stability of the file as a version that corresponds exactly to
the official paper version in the university department library.
Would it be of any use to anyone if I wrapped the name of each
author/ editor in a span class='fn' if I otherwise leave my
markup the way it is now?
A formatted name is quite a restricted format, and if the formatted
name doesn't follow a certain prescribed format, it is considered
to be invalid and isn't used.
What about class='n'?
Currently the BibTeX is as follows
@Misc{AXML,
editor = {Tim Bray and Jean Paoli and C.M. Sperberg-McQueen},
title = {The Annotated XML 1.0 Specification},
year = {1998},
publisher = {O'Reilly Media, Inc.},
refdate = {2007-03-04},
url = {http://www.xml.com/pub/a/axml/axmlintro.html}
}
From which you are wanting to create the following kind of data.
[AXML]
The Annotated XML 1.0 Specification. Tim Bray, Jean Paoli and
C.M. Sperberg-McQueen, editors. O’Reilly Media, Inc., 1998. http://
www.xml.com/pub/a/axml/axmlintro.html (referenced: 2007-03-04)
The editor section alone will be interesting to markup, because the
citation will have to allow multiple editors, in which case both
the BibTeX and the microformat will have to be created from a
parent source, so that the microformat can gain the name-based
information in the format required, while still allowing that
information through to become the BibTeX file.
The current markup is:
dt id=ref-AXML[AXML]/dtddpa href=http://www.xml.com/pub/a/
axml/axmlintro.htmlcite class=titleThe Annotated XML 1.0
Specification/cite/a. span class=editorTim Bray, Jean Paoli
and C.M. Sperberg-McQueen/span, editors. span
class=publisherO’Reilly Media, Inc./span, span
class=year1998/span. span class=urlwrapa href=http://
www.xml.com/pub/a/axml/axmlintro.html class=urlhttp://www.xml.com/
pub/a/axml/axmlintro.html/a (referenced: span
class=refdate2007-03-04/span)/span/p/dd
So to extract the editors from span class=editorTim Bray, Jean
Paoli and C.M. Sperberg-McQueen/span, one would need to know that
it is OK to split on , and and . I could wrap each name in a
span with a class. But what class?
The benefits are that people visitng your content with next
generation tools wil be able to easily extract and use the
information in more interesting and useful ways.
So basically, my effort would not be about catering to specific
realistic foreseeable use cases. Instead, it would be about
putting data out there in case someone figures out a use case
later on.
It may be more useful to provide the ISBN number for the book. Then
the problems left to be solved become smaller and easier to handle.
Sorry, but I don't follow. What's the book?
Somehow, I was under the impression that hCite required
bibliography items as lis instead of dt/dd pairs (which is
what I use and what W3C and WHATWG specs use).
I'm sure that design patterns can be created to accommodate such a
scheme.
What I'm trying to say is that I think hCite should allow names to
be marked up as formatted names tossing the deformatting problem
to the consumer. After all, one of the most popular bibliography
data format, BibTeX, stores formatted names.
Currently the formatted names are accepted in the following formats
given-name (space) family-name
family-name (comma) given-name
family-name (comma) given-name-first-initial
family-name (space) given-name-first-initial (optional period)
In the .bib, there are names that don't follow those formats. For
example:
Michael I. Schwartzbach
C. M. Sperberg-McQueen
Arnaud Le Hors
Simon St. Laurent
Håkon Wium Lie
Geert Jan Bex
Jan Van den Bussche
Henrik Frystyk Nielsen
Roy Thomas Fielding
I'd rather not develop heuristics
