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> &lt;<a href="mailto:bdarcus.lists@gmail.com">bdarcus.lists@gmail.com</a>&gt; 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.&nbsp; 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.&nbsp; atitle is also used in books to denote a
chapter or bookpart.&nbsp; It's also used to identify the specific
proceeding from a conference.&nbsp; 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.&nbsp; Currently there are 'book', 'journals',
'dissertations' and 'patents' (as well as dc and marcxml).&nbsp; 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.&nbsp; 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.&nbsp; 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.&nbsp; 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.&nbsp; One of the
'genres' for book is 'report'.&nbsp; 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.&nbsp; 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.&nbsp; We're talking about flat data
structures.&nbsp; There are no relations to work with in a 'published
HTML citation'.&nbsp; How your citation manager deals with it, or how
the backend database that produces these citations deal with it is
entirely different matter.&nbsp; For display, they are flat.<br>
<br>
-Ross.<br>
</div></div><br>