Let me be clear, I do not care if OpenURL is used as an hCite
format. I do very much care that whatever is chosen is very
easily translated to something OpenURL link resolvers can handle.<br><br>
Now on to clear up the confusion surrounding OpenURL.<br>
<br><div><span class="gmail_quote">On 3/29/06, <b class="gmail_sendername">Bruce D'Arcus</b> <<a href="mailto:bdarcus.lists@gmail.com">bdarcus.lists@gmail.com</a>> wrote:</span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">But the XML representation is basically the same notion: key/values in XML.</blockquote><div>
<br>
No, it's not. They are key/values based /contextually/ on what the thing is.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Consider these elements:<br><br>atitle<br>title<br>stitle<br>jtitle<br><br>We have three that are speciic to journals. One should be able to just
<br>have title and short-title and use those in ANY resource.</blockquote><div><br>
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.<br>
</div><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">It's just that when one adopts that flat approach, then in order to<br>encode different resources, one has to add new properties, which tools
<br>then have to updated to understand. So if I need to encode a<br>conference paper, then that suggests we need to add:</blockquote><div><br>
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. <br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">ptitle<br>ctitle</blockquote><div><br>
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.<br>
</div><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The coding of authors has similar issues (in addition, it uses very<br>Western -- even U.S. -- specific name structures).
</blockquote><div><br>
So do the publishers. What's your solution to this?<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Isn't it just easier and more robust to exploit the fact that you can<br>use more than one class, or containment?
</blockquote><div><br>
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.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>It's not that they -- per se -- are lacking. It's that I cite far more<br>than journal articles and books: archival documents, government
<br>reports, legislation, media sources.</blockquote><div><br>
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.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">OpenURL has to adopt the flat approach because it's primary use case<br>is to provide a url.
</blockquote><div><br>
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.<br>
</div><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I guess my point is it's hard to fit a square peg (relational bib<br>data) in a round hole (flat data structures).
</blockquote><div><br>
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.<br>
<br>
-Ross.<br>
</div></div><br>