Difference between revisions of "Service Registration"

Revision as of 18:46, 27 March 2006

Registering Services using the MR (draft)

Recent discussions about making related services available through the MR, as well as the need to manage ingest of augmented metadata, annotations, and exhibits, make it necessary to find some ways (preferably simple) to expand the available collection/item model to one that accommodates other categories. Ideally, these other categories would be simple, arbitrary and parallel in some ways to collection/item, so that specific metadata records can be included, excluded, highlighted or related as we determine need.

Option 1

Option one allows for a simple expansion of the collection/item model to allow for a service record to be entered at the collection level to enable ingest of item level data. The assumptions for that sort of record might be:

1. Creation would be as a collection record using slightly different defaults/descriptive conventions
   • Elements and default values for a service might be:
     • GEM categories but perhaps not LCSH?
     • Descriptions of services would include service boundaries, methodologies, etc. (do we need more than one level of description, one for display to the public?)
     • Identifier could link to a website with extended information about the service, or a site where extended interaction with the service is provided (or both, ref. DC UB discussion on identifier)
     • Use one DCMIType = Service (is status as collection also inferred from membership in Collections or do we need both Type values?)
     • No Format? (Isn’t format irrelevant here?)
   • Possible Issue: what if iVia supplies LCC for three collections only (all collections don't need the LCC added, perhaps). How do we track which collections need/have iVia augmentations? Do we need to? Do we want to? (think about identifying metadata NEEDING augmentation to a service, as well as how to match the supplied augmentations with the appropriate MR data over multiple iterations of updates, both of the original metadata and the augmentations, in any order.)
   • Display to users who want to see services or to all? How confusing would this be? (We could exclude as a class from display, if we wished)
   • Augmented metadata and/or annotations would be harvested as items [Should they have any defaulted type category to identify them and allow inclusion/exclusion? Or would relation to a service record rather than a collection record do some of this for us?] We could use the NSDLType list for this; XML schema already exists and it's already legal in nsdl_dc. Note that as of 4/22/04, the only two NSDLTypes are "Exhibit" and "News", but it is set up like the GEM schema and so it is easy to add new NSDLTypes.
   • What about brands? Where would a brand link lead? Would we need a different default for service brands?
   • [need examples] Aska services, ENC, iVia, etc. (May need in particular to describe use of sets)

Option 2

1. Specify separate schema (meaning record type?) for services distinct from collections [look up WSDL requirements and see how they relate to this?]
2. Use one DCMIType = Service (separate schema will necessitate this level of separation from collections?)
3. Display to users would depend on whether there was adequate descriptive data to support display
   • Other issues same as Option 1

Other issues:

1. This seems to fit into the issues we’ve identified for annotations? (e.g. is the collection record for annotations a service record?
2. Do we need a general record type for annotation items (in addition to the specific annotation types in the draft format), as well as for augmentations and exhibits? Does this imply that Services always need a special flavor of item? (Item/annotation, item/augmentation, item/exhibit?)

   * Q: will annotations have some sort of aggregation (collection) record?
   * A: yes, and the aggregation record will have metadata pertaining to the annotation service from which we harvest annotation records ...

.

.