info:sid/localhost:CollectionWikiPages:IdentifierResolver info:sid/localhost:CollectionWikiPages CollectionWikiPages http://alcme.oclc.org:80/wikid/search/WikiDb.localhost IdentifierResolver display Wiki Pages userAssigned mailto:jyoung@oclc.org no info:sid/localhost:CollectionSimpleSchemas:wiki info:sid/localhost:CollectionExternalSchemas:xhtml info:sid/localhost:CollectionExternalSchemas:xhtml 1.1 1 87bks7 300 http://www.oclc.org/schemas/WikiRepository xml http://alcme.oclc.org:80/wikid/docs/WikiRepository info:sid/localhost:CollectionWikiPages:IdentifierResolver anonymous CollectionWikiPages 2005/11/18/16 inf_3asid_2flocalhost_3aCollectionWikiPages_3aIdentifierResolver_5f20051118160329217 text/xml CollectionWikiPages:IdentifierResolver 2005-11-18 2005-11-18 1 1.1 repos.hasDate = "hasdate" and oai.identifier exact "info:sid/localhost:CollectionWikiPages:IdentifierResolver" cql.any = huh? 1 1 xml default 2005-11-18 http://alcme.oclc.org:80/wikid/docs/WikiRepository/2005/11/18/16/inf_3asid_2flocalhost_3aCollectionWikiPages_3aIdentifierResolver_5f20051118160329217 = Identifier Resolver = Here is an overview of OpenURL 1.0 as it relates to a proposed identifier resolver. You might want to skip ahead to the Identifier Resolver Example below and then refer back to the underlying principles afterward. == OpenURL Principles == OpenURL 1.0 is a web-service API for performing context-sensitive services. The example below assumes a library patron reading a full-text article in FirstSearch and finding a citation that they want to pursue. The context of the request is encoded in a ContextObject that contains combinations of these six entity types: 1. Referent (required, non-repeatable): the referenced entity (e.g. a book) 2. Referring Entity (optional, non-repeatable): the entity that references the referent (e.g. a journal article that cites the referent book) 3. Requester (optional, non-repeatable): the entity performing the request (e.g. the end-user who clicks on the cited book link in a journal article) 4. Service Type (optional, repeatable): the type of service being requested (e.g. delivery of an online abstract or ILL for the cited book) 5. Resolver (optional, repeatable): The entity at which the request for service is being targeted (e.g. the end-user’s local SFX system) 6. Referrer (optional, repeatable): the entity that generated the ContextObject (e.g. FirstSearch) OpenURL 1.0 allows each of these entities to be identified in various ways: 1. by URI: E.g. DOI, ISBN, OCLC#, etc. 2. by metadata E.g. MARC, Dublin Core, etc. 3. by private data (as negotiated between the referrer and the resolver) There are other layers of abstraction (e.g. inline vs. by-value vs. by-reference and XML vs. key-encoded values, etc.), but for the sake of overview I will ignore them. == Identifier Resolver Example == Here is an example of how OpenURL 1.0 can be used for the identifier resolver. Imagine that we have instcode OSU and we want to get various kinds of results, depending on the situation. http://idresolver.oclc.org/openurl?rft_id=info:sid/oclc.org:instcode:OSU The instcode referent (rft) is specified as a URI and no other context entities are given. In this case, our resolver would perform some default service, such as return an HTTP redirect to the home page for that institution or perhaps return an XML metadata record for it. If we want the service to return the instnum instead, we might add a service type (svc) to override the default: http://idresolver.oclc.org/openurl?rft_id=info:sid/oclc.org:instcode:OSU&svc_id=info:sid/oclc.org:svc_id:instnum I hope people see the value of using URIs to specify entities (rft_id and svc_id), but if not we can always switch to “private data” entities (rft_dat and svc_dat) instead: http://idresolver.oclc.org/openurl?rft_dat=instcode:OSU&svc_dat=instnum In some cases, we may want to provide different results depending on other types of context information (see the list of entity types in the principles above). In general, new services can be added to the OpenURL framework by implementing a simple Java interface. The business logic and ContextObject entity processing within these classes can be as simple or complex as necessary.

Identifier Resolver

Here is an overview of OpenURL 1.0 as it relates to a proposed identifier resolver. You might want to skip ahead to the Identifier Resolver Example below and then refer back to the underlying principles afterward.

OpenURL Principles

OpenURL 1.0 is a web-service API for performing context-sensitive services. The example below assumes a library patron reading a full-text article in FirstSearch and finding a citation that they want to pursue. The context of the request is encoded in a ContextObject that contains combinations of these six entity types:

  1. Referent (required, non-repeatable): the referenced entity (e.g. a book)
  2. Referring Entity (optional, non-repeatable): the entity that references the referent (e.g. a journal article that cites the referent book)
  3. Requester (optional, non-repeatable): the entity performing the request (e.g. the end-user who clicks on the cited book link in a journal article)
  4. Service Type (optional, repeatable): the type of service being requested (e.g. delivery of an online abstract or ILL for the cited book)
  5. Resolver (optional, repeatable): The entity at which the request for service is being targeted (e.g. the end-user’s local SFX system)
  6. Referrer (optional, repeatable): the entity that generated the ContextObject (e.g. FirstSearch)

OpenURL 1.0 allows each of these entities to be identified in various ways:

  1. by URI: E.g. DOI, ISBN, OCLC#, etc.
  2. by metadata E.g. MARC, Dublin Core, etc.
  3. by private data (as negotiated between the referrer and the resolver)

There are other layers of abstraction (e.g. inline vs. by-value vs. by-reference and XML vs. key-encoded values, etc.), but for the sake of overview I will ignore them.

Identifier Resolver Example

Here is an example of how OpenURL 1.0 can be used for the identifier resolver. Imagine that we have instcode OSU and we want to get various kinds of results, depending on the situation.

http://idresolver.oclc.org/openurl?rft_id=info:sid/oclc.org:instcode:OSU

The instcode referent (rft) is specified as a URI and no other context entities are given. In this case, our resolver would perform some default service, such as return an HTTP redirect to the home page for that institution or perhaps return an XML metadata record for it. If we want the service to return the instnum instead, we might add a service type (svc) to override the default:

http://idresolver.oclc.org/openurl?rft_id=info:sid/oclc.org:instcode:OSU&svc_id=info:sid/oclc.org:svc_id:instnum

I hope people see the value of using URIs to specify entities (rft_id and svc_id), but if not we can always switch to “private data” entities (rft_dat and svc_dat) instead:

http://idresolver.oclc.org/openurl?rft_dat=instcode:OSU&svc_dat=instnum

In some cases, we may want to provide different results depending on other types of context information (see the list of entity types in the principles above). In general, new services can be added to the OpenURL framework by implementing a simple Java interface. The business logic and ContextObject entity processing within these classes can be as simple or complex as necessary.