- From: Judith Slein <slein@wrc.xerox.com>
- Date: Tue, 11 Feb 1997 12:54:53 PST
- To: w3c-dist-auth@w3.org
- Cc: lagoze@cs.cornell.edu
The Warwick Framework defines a simple architecture for metadata that is intended to be used both for transport and for persistent storage. My understanding is that there are no plans to put this on any standards track, so it is not something we could just reference. It's worth looking at, however. It's similar to our approach in some ways -- in particular, it treats metadata as resources. The nature of the reference from a resource to its metadata is not defined, so it could be implemented as a link. The major differences are that the metadata is collected into a single resource, rather than having a separate resource for each attribute. And a reference back from metadata to its resource is implemented as a special metadata element. Here's a summary: There are two kinds of objects in this architecture: CONTAINERS and PACKAGES. CONTAINERS contain PACKAGES. There are three types of PACKAGES: METADATA SETS, INDIRECT, and CONTAINER. WF starts with the notion that there will be many different attribute schemata for different purposes and different audiences -- the DAV schema, the Dublin Core schema, the MARC schema, etc. (There will be mappings between some of these schemata, but those mappings are outside the scope of the Warwick Framework.) An object's metadata that belong to the same schema get bundled into a single resource called a METADATA SET, which is a type of PACKAGE. So an object may have many METADATA SETS that may be distributed across multiple servers. (But any single METADATA SET must reside on a single server?) INDIRECT PACKAGES are references to other PACKAGES (only METADATA SETS? CONTAINERS? other INDIRECTS?) To allow for recursive structures, a PACKAGE may also be a CONTAINER. A METADATA SET may be an addressable resource that may have its own metadata, or it may be embedded in a CONTAINER. A CONTAINER may be a resource, but it need not be. It is possible for the CONTAINER and the object (data, content) it belongs to, to be treated as a single resource. WF distinguishes between metadata that was created by the manager or owner of an object, and metadata created by someone else, so that the owner of the object may not even be aware this metadata exists. The former is an INTERNALLY-REFERENCED CONTAINER and is either wrapped with the content or referenced by it. The latter is an EXTERNALLY-REFERENCED CONTAINER and is not known to the content object. A special metadata element called LINKAGE that resides directly inside a CONTAINER may be used by INTERNALLY-REFERENCED metadata to point back to the content object (must, if the metadata is separate from its content?), and must be used by EXTERNALLY-REFERENCED metadata for this purpose. That's it. A MIME implementation of WF has been proposed, using multipart/related, multipart/mixed, or multipart/alternative -- or some combination of these, depending on the situation. So to transfer a data object with three of its METADATA SETS, you would use a multipart/related body that contained the data object as one part, and a multipart/mixed part that contained the three METADATA SETS. So how would this work for us? Schemata get registered somehow. A MIME type for each schema get registered, unless an existing MIME type can be used. Metadata can have metadata to any level of nesting desired. Metadata can be shared by many resources. Metadata sets and containers can get very large, and WF seems to envision only transporting entire containers. There is no way to manage custom attributes. There is no way to find out what attributes a resource has except by retrieving them all. Out of scope: Finding out syntax / semantics of schemata, finding out what schemata a server supports. Getting metadata: If metadata is wrapped with resource If metadata is referenced by resource Get the link to the metadata container Get the metadata container Parse it for the package / attribute you care about Setting (internally-referenced) metadata for a new resource: If metadata is wrapped with resource If metadata is separate from resource Edit metadata sets and a container for them (with the LINKAGE metadata element set to point to the resource) SETLINKVAL puts the container, creates link from resource to container (More complicated if container has INDIRECT PACKAGES pointing to METADATA SETS) Updating existing (internally-referenced) metadata: Get the link to the metadata container Get the metadata container Parse it for the package you care about Edit the package SETLINKVAL puts the container (the link already exists) Deleting an attribute: Same as Updating existing metadata Deleting a METADATA SET: If it's directly in a CONTAINER Same as Updating existing metadata If it's referenced by an INDIRECT PACKAGE Get the link to the metadata container Get the metadata container Parse it for the package you care about Follow the pointer to the package Delete the package Edit the pointer out of the container SETLINKVAL puts the container (the link already exists) Managing resources that have attributes: Because CONTAINERS have LINKAGE metadata elements for each resource they belong to, it's possible for servers to figure out whether it's ok to delete a CONTAINER, how to preserve integrity on a MOVE, etc. Index / Search: Again, all the information needed to support search is available. --Judy Name: Judith A. Slein E-Mail: slein@wrc.xerox.com Internal Phone: 8*222-5169 External Phone: (716) 422-5169 Fax: (716) 265-7133 MailStop: 128-29E
Received on Tuesday, 11 February 1997 15:52:48 UTC