[uf-discuss] citation microformat encodings

[Tim White]

It seems that we need to refocus on what we are trying to do with a
citation micoformat. What problem are we trying to solve?

For me, I'm not out to replace OpenURL, Coins, or any other system. I'm
simply interested in a good way to present bibliographic data (from a
simple book title to a partial citation to a full-blown MLA citation)
in HTML.

Hopefully the result of our work will result in a modular and flexible
format that everyday people can use in their blogs, etc; a structure
that the Amazon.com's could adopt; something we could implement at work
in our online catalog.

And, as a result, perhaps those working with libraries will be able to
harvest information and translate it into/out of a format that they
need. I think hCard is a brilliant example of what can be done with
standardized markup.

The discussion of OpenURL, et al. is informative. These formats exist
and so it only makes sense to look at what they've done and see where
it leads us.

That's what I'm after. Anyone else?

Tim

PS: Ross, that's a great intro to OpenURL. I've only been familiar with
the everything-in-the-url bit before. Thanks.


--- Ross Singer <ross.singer at library.gatech.edu> wrote:

> Yeah, this is a good question which I meant to address... but deleted
> 
> the first msg that I intended to respond to, then got stuck in back
> to 
> back meetings...
> 
> I think there is (understandable) confusion about OpenURL and how it 
> relates to link resolving and why we library-types care so much about
> 
> this working well in microformats.
> 
> First I think clarification of something Tantek wrote needs to be
> made:
> 
> > One point on OpenURL - as far as I can tell, all the information
> about the
> > citation is captured in the URL.
> >
> > The problem is that this is NOT the way people publish citations
> typically
> > on the web.
> >
> > Examples I have seen all have *human visible* text in the page,
> e.g. the
> > name of the publication, author, date, maybe publisher etc.  All
> has 
> > text in
> > the page - not as attributes, nor as part of one big attribute
> value.
> >
> > In short, OpenURL is *not* human friendly and does not convey human
> > *visible* information.  In addition, by its dependency on a
> specific "link
> > server" in order to be of any use at all, it does not encourage
> > *decentralized* development.
> 
> 
> One of the obstacles in explaining OpenURL is the discongruity
> between 
> "the spec" and "the implementation".  While, yes, what you see in 
> practice is a url with the metadata encoded as arguments in the query
> 
> string, this is merely a representation of the "ContextObject"
> intended 
> to be sent to a link resolver to permit services based on the
> contextobject.
> 
> Let's back up, shall we?
> 
> An OpenURL consists of two independent parts:  the ContextObject (or
> the 
> bibliographic metadata surrounding a citation) and the location of 
> resolver to parse the metadata and present contextual services based
> on 
> said metadata.  The (very real) problem is that the term "OpenURL" is
> 
> also used as a catch-all for all of the independent parts and how
> they 
> work.  This is mainly because it's a catchier term than "Z39.88",
> which 
> is the NISO standard all this is based upon.
> 
> So, when Tantek pointed out that this is very non-human readable url 
> string, that is a *particular representation* of the OpenURL 
> ContextObject (which is referred to as "San Antonio Profile 1" --
> more 
> commonly SAP1 -- and is represented in Key Encoded Values -- KEVs).  
> This "representation" is independent of the ContextObject (from here
> on 
> known as CO) itself and is only intended to permit the CO to be 
> transmitted via an HTTP GET request (more on this in a bit).
> 
> There is also SAP2, which is an XML representation of the CO (see:  
>
http://alcme.oclc.org/openurl/servlet/OAIHandler?verb=GetRecord&metadataPrefix=oai_dc&identifier=info:ofi/fmt:xml:xsd:ctx
> 
> and the "Implementation Guidelines" link from that page for more 
> information) and is a much more human readable format.  This still 
> (obviously) falls outside the scope of microformats, but makes the
> point 
> that encoding has nothing to do with the CO itself.  They are just 
> agreed upon means of conveying the CO to enable machines act upon
> them 
> consistently.
> 
> The ContextObject could be conveyed just as easily in XHTML using 
> attributes, as long as the terms follow the vocabulary defined in the
> 
> OpenURL framework.  The important thing to focus on here is the 
> ContextObject -- the address of the link resolver /is/ 
> institution-specific and should be handled by a user's (or machine's)
> 
> activating agent.
> 
> However, the link resolver is still a very important component to
> this 
> whole process.  Getting users "appropriate copy" is a very real (and 
> very difficult) problem that libraries are trying to solve.  Link 
> resolvers are a pretty efficient means of overcoming this hurdle, so
> it 
> would make sense to mark up bibiographic citations in a way that link
> 
> resolvers can easily parse.
> 
> I hope this clears up a little bit of the confusion.
> -Ross.
>


~ Tim

<a href="http://www.tjameswhite.com">www.tjameswhite.com</a>

<a href="http://www.spreadfirefox.com/?q=affiliates&amp;id=12227&amp;t=1">Get Firefox!</a>

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com