I'd like to hear what others have to say on this topic as I know there
are not yet many CPs that expose entityID as an attribute of an
entity.
>>> Paul Trevithick <
paul@xxxxxxxxxxxxxxxxx> 09/03/08 10:04 PM >>>
Jim,
Sounds like you think there*s good utility in keeping it the way it
is.
You may well be right. My reason for changing it is that doing so
brings
Higgins* CDM closer to RDF. It might not be a good enough reason. In
fact, for folks that couldn*t give a hoot about RDF I realize that
this
is reason at all!
However, for those of us like me who already see CDM from a semantic
(if
not entirely from a syntactic) POV as being very close to RDF (and who
like the power of RDF and the cool RDF tools), it makes CDM even
easier
to explain relative to RDF. E.g. We can say quickly that *CDM has
the
semantics of RDF plus a few syntactic transforms, plus Contexts, plus
a
more powerful identifier (UDIs vs. HTTP-URIs).*. If we keep EntityIDs
as
attributes (as they are in IdAS today) then we have another difference
to explain. Namely, a kind of automatic copying of the entity*s
intrinsic identity (its id) into an attribute of the identity. I know
that sounded weird, but in RDF the id IS the thing, it isn*t an
attribute of the thing. Or said another way, in RDF every id IS a node
in the RDF graph whereas attributes (properties) are links from the
node
to literals or other nodes.].
Stepping back a bit, I just want to reiterate that as we all know, our
common goal is to make IdAS a great API for java developers. To do so
we*ve developed CDM * a set of abstractions that are at a higher
level than RDF triples and more convenient to work with [I doubt
there*s
much argument about that!]. So if the consensus is that the IdAS API
(and thus CDM) is better served by keeping this
*auto-entityId-attribute