[uf-discuss] Citation format straw proposal on the wiki

[Ross Singer]

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.

Now on to clear up the confusion surrounding OpenURL.

On 3/29/06, Bruce D'Arcus <bdarcus.lists at gmail.com> wrote:

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/discuss/mail/microformats-discuss/attachments/20060329/c29c0a5d/attachment.htm