Attributes: Warwick Framework

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