info:sid/localhost:CollectionOpenUrlObjectModel:OomBackground info:sid/localhost:CollectionOpenUrlObjectModel CollectionOpenUrlObjectModel http://alcme.oclc.org:80/wikid/search/WikiDb.localhost OomBackground display OpenURL Object Model (OOM) Documentation for the OpenURL Object Model (OOM) userAssigned mailto:jyoung@oclc.org no info:sid/localhost:CollectionSimpleSchemas:wiki info:sid/localhost:CollectionExternalSchemas:xhtml info:sid/localhost:CollectionExternalSchemas:xhtml 1.1 1 s7f68m 300 http://www.oclc.org/schemas/WikiRepository xml http://alcme.oclc.org:80/wikid/docs/WikiRepository info:sid/localhost:CollectionOpenUrlObjectModel:OomBackground anonymous CollectionOpenUrlObjectModel 2007/07/09/12 inf_3asid_2flocalhost_3aCollectionOpenUrlObjectModel_3aOomBackground_5f20070709124123308 text/xml CollectionOpenUrlObjectModel:OomBackground 2007-07-09 2007-07-09 1 1.1 repos.hasDate = "hasdate" and oai.identifier exact "info:sid/localhost:CollectionOpenUrlObjectModel:OomBackground" cql.any = huh? 1 1 xml default 2007-07-09 http://alcme.oclc.org:80/wikid/docs/WikiRepository/2007/07/09/12/inf_3asid_2flocalhost_3aCollectionOpenUrlObjectModel_3aOomBackground_5f20070709124123308 = OpenURL Object Model (OOM) Background = Before we look closely at the OpenURL Object Model, there are two different ways to view OpenURL that have caused confusion and need to be clarified. The original version, OpenURL 0.1 (http://alcme.oclc.org/openurl/docs/pdf/openurl-01.pdf''''''), was specified as a citation-linking protocol. This caught on well in the library community and is what most people think of when you mention “OpenURL”. The subsequent OpenURL 1.0 specification, however, took a different approach. Rather than defining an explicit protocol, OpenURL 1.0 (http://alcme.oclc.org/openurl/docs/pdf/z39_88_2004.pdf'''''') defines a framework for specifying protocols in general. The basic model in this framework is simple and intuitive, but suffers from several problems. First, the model is very abstract. For example, OpenURL 1.0 revolves around the intuitive but vague concepts of “what”, “who”, “where”, and “why”. The second problem is that the OpenURL 1.0 specification gave these simple concepts obfuscated names like “referent”, “requester”, “referring entity”, and “service type” respectively. The third problem is that the specification doesn't differentiate between core features and advanced features that many applications shouldn't have to worry about. I've tried to address the third problem by starting a blog (http://q6.oclc.org/openurl/simple_openurl/''''''). The second problem can be overcome by keeping a printout handy of the terminology mapping. The first problem takes some getting used to, but should quickly become second-nature. Given this clarification, I would assert that OpenURL 1.0 represents a simple, intuitive, flexible, and lightweight model for specifying web services. This is achieved by normalizing the inputs of an operation into generic “what”, “who”, “where”, and “why” containers. Operations can be implemented against this normalized representation, with one or more bridges created between the normalized representation and the protocols that could be used to invoke it. Because these categories are so abstract, it should be possible to imagine that almost any web service could be represented in this way. Another problem with OpenURL 1.0 needs to be pointed out. The conventional way to manifest an OpenURL 1.0 application is to create entries in the OpenURL Registry (http://www.openurl.info/registry/''''''). This isn’t the only way, however. The OpenURL Object Model (OOM) takes a different approach. OOM is to OpenURL as DOM is to XML. For example, the XML specification defines concepts like “element”, “attribute”, “node”, etc. just as the OpenURL specification defines concepts like “entity”, “descriptor”, “transport”, etc. OOM maps its concepts to the programming space in a language-independent way just like DOM does. The expectation is that these conceptual models would get mapped to specific languages in similar ways. For example, in the case of Java, the classes for DOM have been specified by a set of interfaces under the org.w3c.dom.* package. Something analogous has been done for OOM under the info.openurl.oom.* package (http://pubserv.oclc.org/oomRef-j/jars/dist/docs/dist.html''''''). If you examine the classes in this package, they should all map quite literally to the OpenURL spec. Likewise, there can be many implementations of these interface classes. In the case of DOM, we can look at Xerces and Crimson as alternative implementations of this interface set. In the case of OOM, I have written OOMRef-J as a reference implementation (http://pubserv.oclc.org/oomRef-j/jars/dist/docs/dist.html''''''). The unexpected surprise that was revealed by this exercise was that OOMRef-J turned out to be a simple, lightweight, flexible, and intuitive application framework.

OpenURL Object Model (OOM) Background

Before we look closely at the OpenURL Object Model, there are two different ways to view OpenURL that have caused confusion and need to be clarified.

The original version, OpenURL 0.1 (http://alcme.oclc.org/openurl/docs/pdf/openurl-01.pdf), was specified as a citation-linking protocol. This caught on well in the library community and is what most people think of when you mention “OpenURL”. The subsequent OpenURL 1.0 specification, however, took a different approach. Rather than defining an explicit protocol, OpenURL 1.0 (http://alcme.oclc.org/openurl/docs/pdf/z39_88_2004.pdf) defines a framework for specifying protocols in general. The basic model in this framework is simple and intuitive, but suffers from several problems. First, the model is very abstract. For example, OpenURL 1.0 revolves around the intuitive but vague concepts of “what”, “who”, “where”, and “why”. The second problem is that the OpenURL 1.0 specification gave these simple concepts obfuscated names like “referent”, “requester”, “referring entity”, and “service type” respectively. The third problem is that the specification doesn't differentiate between core features and advanced features that many applications shouldn't have to worry about. I've tried to address the third problem by starting a blog (http://q6.oclc.org/openurl/simple_openurl/). The second problem can be overcome by keeping a printout handy of the terminology mapping. The first problem takes some getting used to, but should quickly become second-nature.

Given this clarification, I would assert that OpenURL 1.0 represents a simple, intuitive, flexible, and lightweight model for specifying web services. This is achieved by normalizing the inputs of an operation into generic “what”, “who”, “where”, and “why” containers. Operations can be implemented against this normalized representation, with one or more bridges created between the normalized representation and the protocols that could be used to invoke it. Because these categories are so abstract, it should be possible to imagine that almost any web service could be represented in this way.

Another problem with OpenURL 1.0 needs to be pointed out. The conventional way to manifest an OpenURL 1.0 application is to create entries in the OpenURL Registry (http://www.openurl.info/registry/). This isn’t the only way, however. The OpenURL Object Model (OOM) takes a different approach. OOM is to OpenURL as DOM is to XML. For example, the XML specification defines concepts like “element”, “attribute”, “node”, etc. just as the OpenURL specification defines concepts like “entity”, “descriptor”, “transport”, etc. OOM maps its concepts to the programming space in a language-independent way just like DOM does. The expectation is that these conceptual models would get mapped to specific languages in similar ways. For example, in the case of Java, the classes for DOM have been specified by a set of interfaces under the org.w3c.dom.* package. Something analogous has been done for OOM under the info.openurl.oom.* package (http://pubserv.oclc.org/oomRef-j/jars/dist/docs/dist.html). If you examine the classes in this package, they should all map quite literally to the OpenURL spec.

Likewise, there can be many implementations of these interface classes. In the case of DOM, we can look at Xerces and Crimson as alternative implementations of this interface set. In the case of OOM, I have written OOMRef-J as a reference implementation (http://pubserv.oclc.org/oomRef-j/jars/dist/docs/dist.html).

The unexpected surprise that was revealed by this exercise was that OOMRef-J turned out to be a simple, lightweight, flexible, and intuitive application framework.