info:sid/localhost:CollectionWikiPages:OpenUrlContextObjectGenerator info:sid/localhost:CollectionWikiPages CollectionWikiPages http://alcme.oclc.org:80/wikid/search/WikiDb.localhost OpenUrlContextObjectGenerator 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 yedhq3 300 http://www.oclc.org/schemas/WikiRepository xml http://alcme.oclc.org:80/wikid/docs/WikiRepository info:sid/localhost:CollectionWikiPages:OpenUrlContextObjectGenerator SomeBody CollectionWikiPages 2005/08/01/10 inf_3asid_2flocalhost_3aCollectionWikiPages_3aOpenUrlContextObjectGenerator_5f20050801103523313 text/xml CollectionWikiPages:OpenUrlContextObjectGenerator 2005-08-01 2005-08-01 1 1.1 repos.hasDate = "hasdate" and oai.identifier exact "info:sid/localhost:CollectionWikiPages:OpenUrlContextObjectGenerator" cql.any = huh? 1 1 xml default 2005-08-01 http://alcme.oclc.org:80/wikid/docs/WikiRepository/2005/08/01/10/inf_3asid_2flocalhost_3aCollectionWikiPages_3aOpenUrlContextObjectGenerator_5f20050801103523313 = OpenURL 1.0 ContextObject Generator = = Background = Some folks on #code4lib expressed an interest in an OpenURL ContextObject Generator web service. After toying with some HTML forms and processor service derived from registered metadata formats (see the collections below), I realized that I don't really understand the problem that needs to be solved. The best I can hope for with the processing service for these forms is to generate a KEV or XML OpenURL metadata-by-value "descriptor". Such a descriptor is only a fragment of an OpenURL ContextObject, however, and can be used to describe one of several kinds of OpenURL "entities": * Referent * Referring''''''Entity * Requester * Service''''''Type * Resolver * Referrer Furthermore, metadata-by-value is only one form of descriptor. Here's the list of possibilities: * metadata-by-value * metadata-by-reference * identifier * private-data The latter three are trivial in comparison to the first, but the permutations of entities and descriptors, not to mention the repeatability of each makes an easy-to-use general-purpose ContextObject generator service unlikely. I ''do'' think there things that can be done to facilitate application-specific needs, though. I can create a REST-style web service that will accept '''any''' kind of input and produce a KEV or XML ContextObject, as long as I know ahead of time what to expect. Each such application can be assigned a URI that would get passed in to the service and used as the key to an XSLT-based solution. I can create this as a WikiD collection, which means this service can be used from the WikiD demo server (http://alcme.oclc.org/wikid/''''''), or downloaded and run locally. If you're interested, you can contact me at mailto:jyoung@oclc.org for details. == Collections == These collections contain copies of MTX and XSD metadata constraints in the OpenURL Registry (http://www.openurl.info/registry/''''''). These constraints are then transformed into XHTML forms using XSLT. The "action" for these forms is a web-service that produces ContextObjects. Note that this ContextObject generator service can be used independently from the forms that are available here. * CollectionOpenUrlMetadataFormatsMtx'''''': Produces a KEV ContextObject containing a single metadata-by-value entity (of the selected type). These forms don't support the full capacity of KEV ContextObjects, but they might be adequate for basic situations. * CollectionOpenUrlMetadataFormatsXsd'''''': I only got as far as form generation for XML ContextObjects. This is where the permutations and repeatability really got out of hand. Since it is impractical to create general-purpose forms, it is difficult to imagine the general-purpose arguments that would be sent to the processor service to transform into ContextObjects.

OpenURL 1.0 ContextObject Generator

Background

Some folks on #code4lib expressed an interest in an OpenURL ContextObject Generator web service. After toying with some HTML forms and processor service derived from registered metadata formats (see the collections below), I realized that I don't really understand the problem that needs to be solved.

The best I can hope for with the processing service for these forms is to generate a KEV or XML OpenURL metadata-by-value "descriptor". Such a descriptor is only a fragment of an OpenURL ContextObject, however, and can be used to describe one of several kinds of OpenURL "entities": Furthermore, metadata-by-value is only one form of descriptor. Here's the list of possibilities: The latter three are trivial in comparison to the first, but the permutations of entities and descriptors, not to mention the repeatability of each makes an easy-to-use general-purpose ContextObject generator service unlikely.

I do think there things that can be done to facilitate application-specific needs, though. I can create a REST-style web service that will accept any kind of input and produce a KEV or XML ContextObject, as long as I know ahead of time what to expect. Each such application can be assigned a URI that would get passed in to the service and used as the key to an XSLT-based solution.

I can create this as a WikiD collection, which means this service can be used from the WikiD demo server (http://alcme.oclc.org/wikid/), or downloaded and run locally.

If you're interested, you can contact me at mailto:jyoung@oclc.org for details.

Collections

These collections contain copies of MTX and XSD metadata constraints in the OpenURL Registry (http://www.openurl.info/registry/). These constraints are then transformed into XHTML forms using XSLT. The "action" for these forms is a web-service that produces ContextObjects. Note that this ContextObject generator service can be used independently from the forms that are available here.