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 http://www.tjameswhite.com";>tjameswhite.com 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
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 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 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] 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
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] [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/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
2007/3/30, Scott Reynen <[EMAIL PROTECTED]>:
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:
>
>
>Different base/base mismatches are corrected
> with
>different efficiencies by the methyl-directed DNA mismatch-
> repair
>system of E. coli
>
> ...
>
>Cell
>...
>
>
>
> Comments?
Maybe this has already been covered and I missed it,
Not that I know of.
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
not
proposing this as actual markup, just how nesting could work):
Different base/base mismatches are corrected
with different efficiencies by the methyl-directed DNA mismatch-
repair system of E. coli
...
Cell
one concern about nesting like this is that common citation formatting
actually nests information about the container inside info about the
contained item. For example, see the journal name in this citation:
Klapper PE, Cleator GM, Dennett C, Lewis AG (1990) Diagnosis of herpes
encephalitis via Southern blotting of CSF DNA amplified by polymerase
chain reaction. J Med Virol 32:261-264
So, in this case we have container info ("J Med Virol") completely
surrounded by contained-item info (authors, year, title before, then
pages after).
I'm not sure this is always the case, but it does point out a problem
in using the nested-hcite element approach, whichever way the nesting
is interpreted.
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,
Can you expand on this point a bit? I'm not really seeing why that'd
be necessary.
Wouldn't it be enough just to say that children of an hCite that are
also children of a child hCite don't apply to the parent hCite?
but that looks to me like a relatively small burden
for parsers in exchange for simpler publishing.
-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
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: ... Than Article: ...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 Thesis 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 THES 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] [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
[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: 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
Re: [uf-discuss] Citation: next steps?
On 8/30/06, Timothy Gambell <[EMAIL PROTECTED]> wrote: 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. Tim, I agree that 'author' is bad for describing things that were not 'authored'. I also see that our wiki page with citation examples in the wild ( http://microformats.org/wiki/citation-examples ) is really heavily biased towards citations of text works. Do you have any examples you could add that show how works of art are being marked up on the web? Is the situation of semantic markup just as bad in the art world as it seems to be in my area? 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 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] Citation: next steps?
On Aug 30, 2006, at 8:29 PM, Michael McCracken wrote: Is the situation of semantic markup just as bad in the art world as it seems to be in my area? Mike, Yeah, the semantic markup situation is pretty messy in the museum world, too. There are some credible efforts to come to some consensus about how we describe works of art, but I'm not going to hold my breath. Do you have any examples you could add that show how works of art are being marked up on the web? Markup examples can be found at http://microformats.org/wiki/ workofart-examples, documention of formats is at http:// microformats.org/wiki/workofart-formats, and brainstorming is at http://microformats.org/wiki/workofart-brainstorming. I'd be happy to add those examples and formats to the citation pages on the wiki, but in the name of keeping hCite simple, I figured it would be best to keep work of art distinct. My plan was to wait for hCite to solidify, and then use workofart as a place for specialized art terms that don't have a place in hCite (for example: materials, technique, provenance, and location). Or, I could forget about that and just try to merge work of art with hCite. What do you think? Thanks, Tim ___ 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
[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/11/07, Tantek Çelik <[EMAIL PROTECTED]> wrote: > + 1 for citation -1 for citation, it is too generic for a root class name. Agreed, I don't like 'citation'. hCitation or hCite would be fine -1 on hBib -Ross. ___ 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 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 s instead of / 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
Re: [uf-discuss] Citation: next steps?
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 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.
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.
Bruce
___
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] 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
[uf-discuss] Re: one citation microformat use case (Michael McCracken)
Speaking from my own viewpoint and that of the BibDesk users I've talked to (generally academics, not librarians - it is a bibtex editor), I think that a complete resource description framework would be welcome, but probably overkill. All we really need is enough metadata to import into our local collections and then reproduce a citation in the MLA/Chicago/insert journal style here/ format. I view hCite as one method to automate that process of publishing such automatically importable data. In BibDesk, we have a feature that lets people view a web page then select the text and choose mappings to bibtex fields (ie, select an author name and click on the author field) - people are doing this markup by hand, and they love that feature! There would be many happy people if this kind of simple mapping was done by markup already. 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? I added a bunch of markup examples to the wiki from databases I use. Their markup seems pretty lame. I wanted to add an example from http://www.citeulike.org/ but the site was unreachable just now - that site imports from the other sites, I believe using screen-scraping plugins. -mikeOn 2/13/06, Ryan Cannon <[EMAIL PROTECTED]> wrote: I agree that the use of hAtom + citation, or even Atom + citation(hCite?) would be a good method to syndicate citation formats. Thediscussion of citations has been kicking up and then dying a numberof 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 framingour 80/20. Most bloggers and less formal writers only definereferences 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 seemto be looking for a locator and authenticity-validator not unlike MLAor Chicago, while librarians and others have been talking aboutincluding 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 tostandardize that process and therefore allow both people and tools tobetter understand the information.--Ryan CannonInteractive Developer MSI Student, School of InformationUniversity of Michiganhttp://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/-- Michael McCrackenUCSD CSE PhD Candidateresearch: 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 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 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 20 to 30 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: John Doe, "Lorem Ipsum," class="pages">20-30 Jane Doe, _Dolor Sit Amet_ class="pages">455Pp. 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: John Doe, "Lorem Ipsum," class="pages">20-23 Jane Doe, _Dolor Sit Amet_ class="pages">320 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: John Doe, "Lorem Ipsum," class="pages cited">20-23 Listing of all pages in a work: John Doe, "Lorem Ipsum," class="pages all">20-30 Saying that the work is x pages long: John Doe, _Lorem Ipsum_ class="pages total">10 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
[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
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
[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 45 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 Thesis 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 THES 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] 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] 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
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: Different base/base mismatches are corrected with different efficiencies by the methyl-directed DNA mismatch- repair system of E. coli ... Cell ... 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): Different base/base mismatches are corrected with different efficiencies by the methyl-directed DNA mismatch- repair system of E. coli ... Cell 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
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
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] 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
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... > > chapter: > stuff > book > A collection of stuff 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] 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 45 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 Thesis 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 THES 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
[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] 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
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
[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
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
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: Roy Rosenzweig , The Park and the People: A History of Central Park. Ithaca, NY: Cornell University Press , 1998. The parser associated the correct TITLE and AUTHOR, however, if I put the publication's title first, then the author name: The Park and the People: A History of Central Park. Roy Rosenzweig . Ithaca, NY: Cornell University Press , 1998. 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
[uf-discuss] hCite status and next steps
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. -Jason ___ 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] [hCite] title
On Jan 31, 2007, at 6:37 AM, Michael McCracken wrote: 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? I believe this comes from the To Do[1] section of the Citation wiki page: using existing class names to mark-up citations. "FN" or Formatted Name, is "The name of the object,"[2] while title means "Job title or functional position of the object." In this context, "FN" makes the most sense for the title of the cited resource. That said, I go back and forth--at times the vcard-stuffed format feels awkward, at other times it makes sense. The question, of course, is whether this topic is even up for debate. While I think "FN" for the title is unintuitive and will be off-putting for new users. As for more examples, I have a few that need work: this report's citations[3] should be fine except for the incorrect root element, and my resume [4] uses your conception of "title". Since neither of these examples conform to anything, and just need to be done, I'm not going to put them up on the wiki, but maybe they can inform the voting. [1]: http://microformats.org/wiki/citation#To_Do [2]: http://microformats.org/wiki/existing-classes [3]: http://www-personal.si.umich.edu/~rcannonz/648/ final_paper.xhtml#references [4]: http://www-personal.si.umich.edu/~rcannonz/resume -- Ryan http://RyanCannon.com ___ 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
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
[uf-discuss] [hCite] Wikipedia Book infobox template
Some potentially discussion about marking up book metadata for the Wikipedia occurs on the talk page for the Infobox template on Wikipedia: http://en.wikipedia.org/wiki/Template_talk:Infobox_Book Here's the template itself: http://en.wikipedia.org/wiki/Template:Infobox_Book I've added the fields they have in their template to the citation-examples page: http://microformats.org/wiki/citation-examples#Book_Infobox -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
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: [uf-discuss] hCite elevator pitch and my bibliography generator
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.
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?
Would it be of any use to anyone if I wrapped the name of each author/
editor in a 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.
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 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.
Somehow, I was under the impression that hCite required bibliography
items as s instead of / 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)
How much granularity does BibTeX allow for when storing the formated
names for Editors?
--
Paul Wilkins
___
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] 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: Lippman, Walter. Public Opinion New York: Free Press 1997. [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 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: 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 watermellon yesterday. I'm not sure how that helps us? whereas: This is a book 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
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... (from each document in the collection) -- Benjamin Hawkes-Lewis ___ 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] [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 or . Microformats are all about NOT changing >user's behavior, but forcing the use of the inline element we >are defining that behavior. > >That said, the element does certainly convey some additional >semantics and SHOULD be used, but i would avoid MUST. This parallels >the element discussion for several other formats. > >-brian Complete agreement; recommend using 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 Q&A. http://answers.yahoo.com/dir/?link=list&sid=396545367 ___ 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:
Chapter Title
Book Title
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:
Book Chapter
Chapter Title
Book Title
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
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [citation]: Brian's outstanding issues 2:
On 9/27/06, Andy Mabbett <[EMAIL PROTECTED]> wrote: Does that cater for the case of a journal article which is later anthologised, verbatim in a book? Does it need to? I'd treat that as a relation (in RDF, or a RDBMS), but it may well be overkill for hCite. Chapter --> isVersionOf ---> Article Bruce ___ 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/07, Michael McCracken <[EMAIL PROTECTED]> wrote: There is a note about using 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 when appropriate, but I'm not concerned about it now. --- 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 or . Microformats are all about NOT changing user's behavior, but forcing the use of the inline element we are defining that behavior. That said, the element does certainly convey some additional semantics and SHOULD be used, but i would avoid MUST. This parallels the element discussion for several other formats. -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] Easy book citations
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
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
[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 ):
Different base/base mismatches are corrected with
different efficiencies by the methyl-directed DNA mismatch-repair
system of E. coli
...
Cell
...
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:
Different base/base mismatches are corrected with
different efficiencies by the methyl-directed DNA mismatch-repair
system of E. coli
...
Cell
...
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] 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: Chapter Title Book Title 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] [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
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] [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: date text 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 2007 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] 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, (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] Citation format straw proposal on the wiki
I suppose it's worth fleshing out what I mean by modularization a bit more, because I think it's all that's neccesary to infer type. Suppose we have a core citation format, such as Tim White shows, containing the following properties/classes. hCite Author (hcard) Title Date Collaborators Description Catalogue Number Then we have properties that are specific to books/journals Pages Volume If these properties are present, then we know that this item is probably not say.. a photo or a painting, and contains all the properties which allow it to be pased the same whether it's a book or a journal. Combine it with hCite and suddenly we have bookCite The properties specific to artwork might be: medium dimensions add them to hCite and we have artCite Then suppose we have properties specific to a photo Aperture Fstop Camera We add those to artCite and suddenly with have photoCite, demonstrated. Ansel Adams Siesta Lake 8x10 view camera Gelatin Silver Print From the presence of "camera" we can glean that this is an instance of photocite. But a generic parse can still glean the Author and Title properties. A domain specific parser has the extra data it needs for cataloguing, or whatever other task required. The domain specific parser could safely ignore hCites lacking any of the properties required for photoCite. Etc. etc. In short, one core format that everything can understand, with properties available for domain specific applications. The careful categorization and "branding" of each module helps to keep things simple for site authors. Basically I'm basing this off the "modularization of xhtml". For instance, most site authors only need the basic modules for xhtml. They have no need for something like the Ruby module. But there's a large portion of the audience that does, and when they need that, it's available as a module. Does that make sense? On Mar 29, 2006, at 7:17 PM, Tim White wrote: Well, this is a lot to process at the end of the day. Here's just a few of my initial thoughts. First, and I've asked this before, what are we trying to do? For me, I just want a *simple* way to mark up books, be it a title, title & author, or slightly more. We are NOT replacing OpenURL, etc. We are NOT building library/scholarly citation records (in my opinion) Those already exist and, as has been shown on the list, are very complicated. They also serve a specialized audience and I don't think reflect the 80/20 of general users. The format should be as simple as possible. As for type attributes (ie, class="book"), Bryan Suda and I had a lengthy discussion a while ago about that. I too believed it was necessary, but came to see that it is purely extraneous metadata. Look at a sample citation, something like: R. Buckminster Fuller. Operating Manual for Spaceship Earth, Pocket Books, 1970, pp. 13, 14. No where does it tell you what this is. We infer (from the blog post in this case) that it is a book. Or, we look it up via Amazon or library card catalog to find that it is a book. Think of hCard. For organizations do we include a type identifier? I.e.: Webs - R - Us. A simple format also makes the MF usable for more than books. Works of art have been mentioned. Just use the same layout: Edvard Munch. "The Scream", 1893. It still has a creator, title and date. --- Alf Eaton <[EMAIL PROTECTED]> wrote: OK, so a minimal microformat for a citation could look like this: Item title n-n [and anything else specific to this particular type of citation] This seems to be on the right track; similar to what I had in mind. At work, we have need of a citation microformat and are going to be using mark up like this for now: "Accelerated Aging: Human Progeroid Syndromes." Author Name. Encyclopedia of Aging. Vol. 1. New York: Macmillan Reference USA, 2002. It's not perfect, but it fits our needs. Transforming that: "Accelerated Aging: Human Progeroid Syndromes." Author Name. Encyclopedia of Aging. Vol. 1. New York: Macmillan Reference USA, 2002. I know it isn't perfect, but it's based on reusing existing MF, and (I hope)in keeping with the principles. (In looking back at it, wouldn't it be possible to do only on vCard, perhaps way up in , that would encompass the author and publisher? Those who know parsing (Brian S.) -- does that screw up hCard parsing?) ~ Tim http://www.tjameswhite.com";>www.tjameswhite.com http://www.spreadfirefox.com/? q=affiliates&id=12227&t=1">Get Firefox! __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___
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
[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
[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]: 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
[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
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] [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: 52.483- 1.893 ___ 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
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. 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/";> Jane Doe http://purl.org/net/biblio#Article"/> Some Title Journal Title http://purl.org/net/biblio#Journal"/> 23 2 123-165 Carl Schmidt Political Theology: Four Chapters on the Concept of Sovereignty 2005 http://purl.org/net/biblio#Book"/> University of Chicago Press Chicago Politische Theologie: Vier Kapital zur Lehre von der Souveranitat Duncker Humbolt Berlin 1922 Bruce ___ 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: 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] 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] 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 ABC Publishing Co. United Kingdom ... John Doe ... Foobar! World Class Book about foobar 1 1 1 1-10 article 12345678 foo bar Published January 1st 1006 Copyright 2006 ... Have you read Foo Bar? It was written by John Doe. It only came out a few months ago 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 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/suggestions there. -brian [1] - http://microformats.org/wiki/citation-brainstorming#Brian.27s_Straw_format -- brian suda http://suda.co.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 format straw proposal on the wiki
On 3/29/06, Breton Slivka <[EMAIL PROTECTED]> wrote: Then we have properties that are specific to books/journalsPagesVolumeIf these properties are present, then we know that this item isprobably not say.. a photo or a painting, and contains all the properties which allow it to be pased the same whether it's a book ora journal. Combine it with hCite and suddenly we have bookCite I just want to point out that ambiguity might not be bad for determining what an item isn't, but it's not good practice for determining what an item is.I am currently going through our 705k marc records trying to determine what each record actually is representing and if it's not explicitly set (which is sadly really only done with conference proceedings and journals) it becomes a guessing game as what these things really are. In my case, I can probably actually find the thing and determine what it is (although that won't scale, obviously), but a citation I might find on the web won't afford me that. Explicitly stating what an item is a much sounder approach.-Ross. ___ 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... 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 sort of agnostic about this (type or no type), but I'm not so sure it follows that one must know a type of a resource to be able to find a copy. Seems to me a good identifier (from which one can infer type) is far more important. 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). Yes, but again: I don't think type is necessary for resolution. If I have a URL, that's enough. If I have a DOI or an ISBN represented as a URI, then also enough. And when you deal with archival documents and such that I sometimes deal with, they typically aren't web resolvable; at all. 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 That would be a reasonable option, though I'd also suggest a more generic "document" fallback (because real world citation practice just doesn't fit pre-defined boxes). Also, *if* you have a container typed as a "journal" then you also need a broader "periodical." (and it's actually trivial to add other formats if necessary -- yes, that's an open invitation to you, Bruce ;)). Only so many hours in a day Ross ;-) You can get a sense of what I consider important by looking at my RDF schema: <http://purl.org/net/biblio> Am currently revising it. Worth noting that the classes have a hierarchy. So a Book is a subclass of Document, and so forth. It makes the typing more robust. Bruce ___ 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 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:
[AXML]http://www.xml.com/pub/a/
axml/axmlintro.html">The Annotated XML 1.0
Specification. Tim Bray, Jean Paoli
and C.M. Sperberg-McQueen, editors. class="publisher">O’Reilly Media, Inc., class="year">1998. http://www.xml.com/
pub/a/axml/axmlintro.html (referenced: class="refdate">2007-03-04)
So to extract the editors from Tim Bray, Jean
Paoli and C.M. Sperberg-McQueen, 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 s instead of / 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 in my end for properly guessing the
semantics of the middle tokens. Espe
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] 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... > > > > (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
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]: 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... chapter: stuff book A collection of stuff 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
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 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 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] citation: another example of practice in the wild
On 8/16/06, Bruce D'Arcus <[EMAIL PROTECTED]> wrote: 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. That *was* recent! My apologies for the sour tone earlier - I honestly thought that was months ago, when it was just July 30th. > > 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. I tried my imagination on one of my straw examples. Does this fit what you were expecting? Lorin Hochstein, Jeff Carver , Forrest Shull , Sima Asgari, Victor Basili, Jeffrey K. Hollingsworth, and Marv Zelkowitz, http://dx.doi.org/10.1109/SC.2005.53";>HPC Programmer Productivity: A Case Study of Novice HPC Programmers. Proceedings of ACM/IEEE Supercomputing Conference 2005 page 35 IEEE Computer Society Washington, DC http://portal";>PDF of full text from ACM DOI: http://dx.doi.org/10.1109/SC.2005.53";>10.1109/SC.2005.53 Tags: http://citeulike.org/tag/productivity"; rel="tag">productivity, http://citeulike.org/tag/hpc"; rel="tag">hpc, http://citeulike.org/tag/performance"; rel="tag">performance In developing High-Performance Computing (HPC) software, One thing I noticed was that there seemed to be no DC term for what I had as 'instantiation', or the link to a copy of the actual resource. Maybe there's somewhere else we can borrow a term from, or was I missing a good choice from DC? 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] 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:
Chapter Title
Book Title
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
[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:
Vicente, Kim J.
Rasmussen, Jens
...
BibDesk[1] also exports the following:
Vicente, Kim J. and Rasmussen, Jens
...
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:
author1
author2
article title
...
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
