Re: [uf-discuss] [citation]: Brian's outstanding issues 2:
On 9/25/06, Ross Singer [EMAIL PROTECTED] wrote: 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. Well, periodical is fine... it could be mapped to journal (and monograph to book -- I mean, that seems like the logical analogy). The labels aren't that important as long as we can kind of match them (and, no doubt, OpenURL is an inexact science). I don't know, there seems to be a balance that can be struck -- universality vs. immediate functionality (and I think some balance needs to be struck in both directions). I agree, and part of it is just defininig a core model that can be logically extended without pain. Goes back to my suggestion that thinking in terms of class hierarchy is helpful. You start with the basics and then if need be, let people extend them. So start with: - Document - Book - Chapter - Article - Report - Collection - Periodical - Journal - Event - Conference ... or something like that. In fact, if someone wants to work with me on revising the documentation for my bibliographic schema (current new working title is Description of Citation Sources (DOCS), but I suck at names, so that might change) to clearly segment out a core set of types per above, I'm happy to do that. Something like this: http://www.users.muohio.edu/darcusb/citations/classes.png 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:
Followup blog post: http://netapps.muohio.edu/blogs/darcusb/darcusb/archives/2006/09/26/reference-types 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:
Michael McCracken mumbled the following on 25/09/2006 23:05: I do agree that using an element with type class instead of a huge number of type classes is the way to go here, to avoid class namespace pollution. Comments? I agree. It follows one of the principles of Minimising Vocabulary, and allows the same class name to be used in multiple uFs. -- Regards, Gazza ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [citation]: Brian's outstanding issues 2:
On 9/25/06, Michael McCracken [EMAIL PROTECTED] wrote: I do agree that using an element with type class instead of a huge number of type classes is the way to go here, to avoid class namespace pollution. I actually don't like using the separate element, in part because this information is usally not displayed, but rather used for processing (styling and conversion). The type does matter for display, in other words, but in more subtle ways that have the user see book. Before we settle this, can we go over the technical arguments against using classes? I know, for example, that Tantek once said it's not generally good practice to double up classes (hcite book) but I'd like some explanation about why. But I will say that in either case, one must allow for extensions. I've worked on this for a long time, and defining a fixed list of types that is anything but arbitrary is pretty much impossible. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [citation]: Brian's outstanding issues 2:
On 9/25/06, Bruce D'Arcus [EMAIL PROTECTED] wrote: On 9/25/06, Michael McCracken [EMAIL PROTECTED] wrote: I do agree that using an element with type class instead of a huge number of type classes is the way to go here, to avoid class namespace pollution. I actually don't like using the separate element, in part because this information is usally not displayed, but rather used for processing (styling and conversion). The type does matter for display, in other words, but in more subtle ways that have the user see book. I know what you mean - the type matters in how you format the reference, but it isn't usually displayed. This is something we'll have to hammer out. Right now it looks like a tradeoff between flexibility and elegance, but I'm hoping for a solution that combines both... Also, when I thought about it, in many cases where the reference is a search result or otherwise not part of a specifically formatted publication, I wouldn't mind the extra word explaining exactly what it is. Before we settle this, can we go over the technical arguments against using classes? I know, for example, that Tantek once said it's not generally good practice to double up classes (hcite book) but I'd like some explanation about why. But I will say that in either case, one must allow for extensions. I've worked on this for a long time, and defining a fixed list of types that is anything but arbitrary is pretty much impossible. I'm not aware of the arguments for/against doubling up. Are you referring to this: http://microformats.org/wiki/hcard-faq#nesting-properties ? The problem I have with using class names to encode the type of a reference is that we end up having a new class name for every type of reference, which as you say is large and arbitrary, and might be considered infinite for any practical purpose. This seems like we're claiming a very large and perpetually undefined set of class names as potential citation type names, which violates the minimal vocabulary principle that Gazza mentioned earlier: http://microformats.org/wiki/naming-principles#Minimal_Vocabulary While that principle isn't fully explained on the wiki, I'd say it's pretty clear that even if we didn't allow arbitrary new class names, we'd still be forced to propose a long list of new class names to cover all the types of cited items. On the other hand, I can imagine wanting to use CSS to display an icon for a book next to a book's reference, or a journal icon for an article. Many current sites do something like this. That's easy enough with class=book, but I'm not familiar enough with CSS to know if that's possible based on the content of an element. I suspect not. Can any CSS experts chime in? 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]: Brian's outstanding issues 2:
On Sep 25, 2006, at 7:35 PM, Michael McCracken wrote: I know what you mean - the type matters in how you format the reference, but it isn't usually displayed. This is something we'll have to hammer out. Right now it looks like a tradeoff between flexibility and elegance, but I'm hoping for a solution that combines both... I'd lean towards what's currently published. If the microformat requires publishers to display more than they are displaying currently, they'll likely either not use it, or use it with some ugly content-hiding hack. Peace, Scott ___ 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, Scott Reynen [EMAIL PROTECTED] wrote: On Sep 25, 2006, at 7:35 PM, Michael McCracken wrote: I know what you mean - the type matters in how you format the reference, but it isn't usually displayed. This is something we'll have to hammer out. Right now it looks like a tradeoff between flexibility and elegance, but I'm hoping for a solution that combines both... I'd lean towards what's currently published. If the microformat requires publishers to display more than they are displaying currently, they'll likely either not use it, or use it with some ugly content-hiding hack. I agree - as I've said before we shouldn't *require* any kind of type information, because human users don't really need them, and (at least for applications I'm most familiar with) programs consuming the format likely have a good fallback type to use when the type isn't obvious. The question is how to allow publishers who wish to include the type to do it in the best way. The separate type element seems to be the lesser of two evils in this case. 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. -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/25/06, Michael McCracken [EMAIL PROTECTED] wrote: The option of just ignoring types altogether - not including a type property at all - is certainly possible - it would make human-reading and publishing easier but automatic parsing somewhat harder. This might be a worthwhile tradeoff. I feel this is a very short-sighted decision, if it's the route hCite goes... You'd never be able to link to an appropriate copy (because you wouldn't be able to determine with any semblance of confidence what an item actually is) and I'm therefore not sure what the point of this is. I guess the way I look at it is this: the entire point of formatting a citation in a standardized way is so that another scholar can then go in and know how to find the item again to follow the first person's research. If the second scholar's /browser/ can do this work, the way that it looks on the screen is rather insignificant (much to the chagrin on the MLA and the APA, but they'll probably be happier in the long run). I've gone on record repeatedly that I don't care if hCite looks like OpenURL as long as it's easy to make something remotely OpenURL from it, but this is a fairly vital part of OpenURL... the very basic notion of knowing what something is. I would recommend that we at least use the basic the journal (journal, article, issue, proceeding, conference, preprint), book (bookitem, book, proceeding, conference, report), dissertation (or thesis), or patent that are currently defined under the San Antonio profile in OpenURL (and it's actually trivial to add other formats if necessary -- yes, that's an open invitation to you, Bruce ;)). No, you don't have to use these labels, but if you want to get the darn thing, choose something that we can map to. Because static, non-actionable lists are so last web trend. -Ross. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [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
