From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
Sent: Wednesday, October 18, 2006
3:30 PM
To: 'Higgins (Trust Framework)
Project developer discussions'
Subject: RE: [higgins-dev]
Representing Metadata in the HigginsOntology
My
predict-o-meter is way off. I assumed you would have answered with a proposal
to add a higgins:metadata, which when present on a DigitalSubject would be
digital subject metadata, and when present on an Attribute would be attribute
metadata (likewise for SubjectRelationship).
I’m definitely warming up to the idea of a higgins:metadata
ObjectProperty. We could create a higgins:metadata Property and then only use
it as an “abstract” (in the Java sense) super Property. Then “real”
metadata properties like higgins:source would simply be defined as
One potential
problem with the proposals below is what happens if we add new properties (we'd
have to update our definition(s) to say "...and which is neither
"higgins:attribute" nor "higgins:relationship nor
"higgins:xyz"."
True, though I can’t for the life of me think what we’d
want to add beyond attributes and relationships, but then again 640k seemed
like a lot of RAM once. In the interest of future-proofing, having a higgins:metadata
property as a kind of “marker” is cleaner.
Regarding
higgins:uniqueIdentifier: At the Raleigh face to face, my impression was that
there would be an attribute with a higgins-specified type used to hold the
cuid, and the IDAS APIs would in effect provide a "shortcut" method
(IDigitalSubject.getUniqueID) to access it. So I guess I expected the
higgins.owl to contain an attribute definition looking something like this:
<owl:ObjectProperty
rdf:about="#uniqueIdentifier">
<rdfs:range rdf:resource="#StringSimpleAttribute"/>
<rdfs:domain rdf:resource="#DigitalSubject"/>
<rdfs:subPropertyOf rdf:resource="#attribute"/>
</owl:ObjectProperty>
(I probably screwed that up)
I could go either way on this one. Since I can see that you feel
there is an advantage in just considering CUID as another Attribute, I’ll
go ahead and change higgins.owl to conform. Actually there may be an advantage in
what you have above. We could define the rdfs:range as #SimpleAttribute and
thereby allow a CUID to be a string, a number, or whatever other literal the
context provider prefers. This also aligns better with Scott Lewis’s
suggestion of using ECF’s ID interface for the CUID. What are your
thoughts on the need to have different kinds of CUIDs?
and assumed
higgins.DigitalSubject would specify a minCardinality of 1 for this
attribute
yes.
On relationships:
IdAS has the notion of things that have relationships (IContext and
IDigitalSubject). Relationships always have a type, metadata, and a
related object. <aside>I guess in the owl, the type is just the
relationship type (so a parentOf relationship would be a subclass of
relationship I suppose). Also, I guess the thing representing the
"related object" in owl is just whatever we decide it is (for a
SubjectRelationship , it's the higgins:contextURI nor higgins:subjectCUID, for
a ContextRelationship, it's just the higgins:contextURI).</aside>
If one sublcasses SubjectRelationship (to makes something like a
ParentRelationship) and adds more properties to that sublcass, would we
automatically assume all the added properties are metadata? I
suppose so.
Yes, though as I mention above, I’m leaning strongly towards
a best practice of “marking” metadata with higgins:metadata
super-Property.
>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
10/17/06 2:13 PM >>>
>
> It doesn't look like we're labeling anything specifically as
metadata. We
> just define a new object property, create a class for it's range, set it's
> domain(s) and that appears to be it. This seems to require that the
> implementor of an IdAS CP will have to have a table that says ... for
> example, "timeSpan" is metadata, not an attribute. Is this
correct?
You're right that the word "metadata" isn't explicitly used anywhere
in
higgins.owl. The semantics of this word are defined by the IdAS API/CPI.
>From the RDF/OWL perspective, we could create a consistent (with IdAS)
definition of higgins:Attribute metadata as:
any RDF property whose domain is higgins:Attribute and which is
neither "higgins:complexValue" nor
"higgins:simpleValue".
And we could define h iggins:DigitalSubject metadata as:
any RDF property whose domain is higgins:DigitalSubject and which
is neither "higgins:attribute" nor
"higgins:relationship"
BTW, I'd have to ask Jim if he thought we should also exclude
"higgins:uniqueIdentifier" or not.
And we could define higgins:SubjectRelationship metadata as:
any RDF property whose domain is higgins:SubjectRelationship
and which is neither higgins:contextURI nor higgins:subjectCUID
>
> I'm trying to define some metadata for a derived ontology we're working on
> and I feel like, especially for derived ontologies, we'll need to
> specificall call things out as metadata. Of course, I may just be
out in
> left field here, so let me give the specific example ... of course, this
> may just be an extension of the Relationship vs. Attribute discussion but
> hey, I'm trying to make progress where I can ...
< BR>Let me know what you think of the above. If that doesn't work for
you, you
can define your own concept (RDF property) in your sub-ontology and create
sub-properties from that. And if that doesn't work, there are other
options...
>
> I want to define an object property, as far as I can tell, as a
> subProperty of a &higgins;relationship.
You can certainly define a sub-property of higgins:relationship, but I would
have thought that its range would be a subclass, C, of
higgins:SubjectRelationship. And I would have thought that it is instances
of C that are the places where you can hang all kinds of RDF properties
(much like our postalAddress example).
BTW, on a related note. I'm still open to changing higgins.owl such that the
higgins:SubjectRelationship is a sub-class of higgins:Attribute as we
discussed last Thursday. Doing so would, through inheritance, give
SubjectRelationship (optional) "metadata" p roperties such as source,
timeSpan, etc. Would that also help?
I want my object property to have
> metadata and, as per the IdAS API, a relationship can have metadata.
> That's good. What do I need to do in my ontology to define this
metadata,
> identify it as metadata, and restrict it to the object property I desire?
Let me know what you think of what I've written above, before I try to
answer further.
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev