Now on to clear up the confusion surrounding OpenURL.
On 3/29/06, Bruce D'Arcus <[EMAIL PROTECTED]> wrote:
No, it's not. They are key/values based /contextually/ on what the thing is.
This is also incorrect. atitle is also used in books to denote a chapter or bookpart. It's also used to identify the specific proceeding from a conference. title and jtitle (in this case) are interchangable (the analog to books is 'btitle'), but you can just use title and be done with it.
The community profiles are designed to handle different resources. Currently there are 'book', 'journals', 'dissertations' and 'patents' (as well as dc and marcxml). The spec is designed to handle /exactly/ what you're talking about here.
No, these would be atitle and title, accordingly. If the proceedings are in a serialized format, you would use the community profile for 'journal' and add the genre 'conference' or 'proceeding', depending on the granularity of the citation. If the conference was published as a monograph, you would use the community profile for book, otherwise the rest the is the same.
So do the publishers. What's your solution to this?
Sure, I think that's what I'm saying, but one of those /had better/ get the user to full-text (or the possibility thereof) or the whole exercise will leave the user wanting.
The spec either does, or can, handle any of these. One of the 'genres' for book is 'report'. Profiles could be created for the other things you mention (and should be -- it would help garner consistency between sources) and adopted by link resolvers.
Currently. Now that we seem to have gotten that part down, we can actually make (and are starting to do) the OpenURL do what it was intended to do.
HTML is a flat data structure. We're talking about flat data structures. There are no relations to work with in a 'published HTML citation'. How your citation manager deals with it, or how the backend database that produces these citations deal with it is entirely different matter. For display, they are flat.
-Ross.
But the XML representation is basically the same notion: key/values in XML.
No, it's not. They are key/values based /contextually/ on what the thing is.
Consider these elements:
atitle
title
stitle
jtitle
We have three that are speciic to journals. One should be able to just
have title and short-title and use those in ANY resource.
This is also incorrect. atitle is also used in books to denote a chapter or bookpart. It's also used to identify the specific proceeding from a conference. title and jtitle (in this case) are interchangable (the analog to books is 'btitle'), but you can just use title and be done with it.
It's just that when one adopts that flat approach, then in order to
encode different resources, one has to add new properties, which tools
then have to updated to understand. So if I need to encode a
conference paper, then that suggests we need to add:
The community profiles are designed to handle different resources. Currently there are 'book', 'journals', 'dissertations' and 'patents' (as well as dc and marcxml). The spec is designed to handle /exactly/ what you're talking about here.
ptitle
ctitle
No, these would be atitle and title, accordingly. If the proceedings are in a serialized format, you would use the community profile for 'journal' and add the genre 'conference' or 'proceeding', depending on the granularity of the citation. If the conference was published as a monograph, you would use the community profile for book, otherwise the rest the is the same.
The coding of authors has similar issues (in addition, it uses very
Western -- even U.S. -- specific name structures).
So do the publishers. What's your solution to this?
Isn't it just easier and more robust to exploit the fact that you can
use more than one class, or containment?
Sure, I think that's what I'm saying, but one of those /had better/ get the user to full-text (or the possibility thereof) or the whole exercise will leave the user wanting.
It's not that they -- per se -- are lacking. It's that I cite far more
than journal articles and books: archival documents, government
reports, legislation, media sources.
The spec either does, or can, handle any of these. One of the 'genres' for book is 'report'. Profiles could be created for the other things you mention (and should be -- it would help garner consistency between sources) and adopted by link resolvers.
OpenURL has to adopt the flat approach because it's primary use case
is to provide a url.
Currently. Now that we seem to have gotten that part down, we can actually make (and are starting to do) the OpenURL do what it was intended to do.
I guess my point is it's hard to fit a square peg (relational bib
data) in a round hole (flat data structures).
HTML is a flat data structure. We're talking about flat data structures. There are no relations to work with in a 'published HTML citation'. How your citation manager deals with it, or how the backend database that produces these citations deal with it is entirely different matter. For display, they are flat.
-Ross.
_______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
