Resolving associated resources in addition to resolving names

["John L. Clark" <jlc6@po.cwru.edu>]

= Abstract =

I need to be able to specify the location of a resource related to a
given resource.  This sort of behaviour is close enough to XML catalog
behaviour that I thought I would bring it up here.  At the same time, it
is definitely a departure from the functionality currently provided by
the XML catalog specification.  The proposed functionality provides a
way to perform entity resolution on a related entity as opposed to
performing entity resolution on the entity itself.

    Aside:

    If this is significantly off-topic for this TC, I would be very
    interested in learning about other work that has been done in this
    area and/or other places to discuss this sort of technology.  In
    some ways this is similar to some of the XML pipeline work that has
    been done, but this is still very solidly in the realm of entity
    resolution, I believe.  I would think this kind of functionality
    would be fairly commonplace, so perhaps this has been resolved with
    a different specification and I have simply missed it.

= Use Cases =

An agent has an RDF statement and needs to locate a schema that
describes the semantics of that statement.

An agent has an XML instance and needs to locate a schema with which to
validate the instance.

An agent has an XML instance and needs to know the location of an
alternate representation of that instance.

= Design Ideas =

I was thinking that this could be accomplished in a manner very similar
to the current 'uri' element (I was thinking of calling the new element
'meta').  This 'meta' element would take an additional attribute,
'type', that would contain a URI of the root namespace of the related
resource (the 'uri' attribute) that would be returned by the resolver.

For example, an agent could query a catalog to find a URI for something
with a root namespace of http://www.w3.org/1999/02/22-rdf-syntax-ns# for
the resource with URI http://purl.org/dc/elements/1.1/.  In this case,
the agent wants the RDFS specification for the Dublin Core elements.
If, instead, the agent wanted an XML schema, it would replace the first
URI with http://www.w3.org/2001/XMLSchema in its query.

I have many more ideas (such as a corresponding rewriteMeta element),
and I am working on a more precise specification, but I wanted to get
some feedback on this idea first.

= Problems =

Currently, there is always a return value for entity resolution.  Even
on failure, the agent using the catalog still knows the original value.
With related entity resolution, there is no initial value, and so
failure leaves the agent empty handed.  Of course, the agent could
simply know to expect this contingency and plan for it.

Does a single type field as described above provide enough flexibility
for catalog maintainers to describe related resources that may need to
be resolved?

= Advantages =

In addition to addressing the use cases presented above, this would
enable namespace maintainers (such as the maintainers of the RDF
specification) to make catalogs publicly available which specify the
locations of specific typed relationships to namespaces under their
management.  Leaf maintainers could then resolve these global catalogs
to local ones and/or individual entries therein, falling back to the
global where necessary.

Take care,

    John L. Clark

PGP signature