[uf-discuss] citation microformat encodings

Ross Singer ross.singer at library.gatech.edu
Wed Jan 25 09:02:17 PST 2006


Scott Reynen wrote:

> I'm not clear on how the existence of link resolvers is relevant to  
> an XHTML microformat adopting OpenURL's metadata labels.  Is everyone  
> talking about the same thing here, roughly what Tim and Ed pointed to  
> [1,2]? 


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.


> Ross Singer wrote:
>
>> In regards to your local (public) library not running one of these  
>> "link resolver" thingamabobs, that's hardly an excuse not find  value 
>> in the technology.  It's only a matter of time before all  libraries 
>> have a link resolver of some sort.  The rise of  electronic resources 
>> has basically rendered the link resolver as  important as the catalog.
>>
>> There are logical reasons that you find it currently at the  academic 
>> level, rather than the public library level - the bread  and butter 
>> of link resolvers (and, indeed, citations and scholarly  research) is 
>> in journal articles.  This is a much larger part of a  university 
>> library budget than a public library's.
>>
>> However, the state of Georgia will be rolling out link resolving  for 
>> all citizens (colleges, public libraries, K-12) this year, so  the 
>> trend is certainly moving "down the library food chain".
>
>
>
> [1] http://www.inkdroid.org/journal/2006/01/18/openurl-as-microformat/
> [2] http://onebiglibrary.net/project/coins/openurl-microformat-for- 
> journals
>
> Peace,
> Scott
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>


More information about the microformats-discuss mailing list