[DAS] Re: Our identifier doc and proposal

[Brian King]

> The pairing of OID and OID_CLASS represent discrete, fixed
> minimum requirements for preservation of information content. 

I don't see why this is true.  The class information is in the datasource,
not the client, so if you have a universally unique ID then the server
should know how to retrieve and construct a class instance.  The data
returned to the client should have enough information to determine the
class.  

I can see that it would be convenient for the client to know the object
class from the identifier prior to the query, but there are other ways to
get that information.  For example, if the ID is a reference within an XML
document, then you may know the class by the context, or at least know a
base class.  Or you could query the server to say "what is the class of the
object with ID 'ZZZZ'".  There have been cases in our systems we've changed
data by moving it into a new subclass. But querying by ID would still return
the same data.  Should the IDs now change to have the subclass name?  Should
I be able to query by encoding either class or superclass in the ID?  Do we
need to specify authority when we specify class to say whose ontology it is?
I don't think embedding this type of meta-data in the ID will be a stable
design.  

Regarding the I3C ID "paths", you're right that this is open to abuse.  I'd
rather call the path a "hierarchy".  It is not a physical path in a
filesystem or a path in a document; it is just a classification of the data
source.  This seems consistent with the URN RFC.

Brian