RE: [higgins-dev] Higgins Ontology Version

>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 8/31/06 10:03 PM >>>
Jim,

In the last couple of days I worked out how to address the requirements
expressed in your email below with our existing higgins.owl. But the
solutions were ugly. I began to see that a cleaner set of solutions could be
achieved if we first make some changes to higgins.owl.

I'll need a couple days to work it all out in detail (and create a new
higgins.owl), but here is the rough idea.

Instead of DigitalSubjects (of any kind/subclass) all using single kind of
hasAttributeStatement whose value (an AttributeStatement) has a rich variety
of property types, we reverse things. We use a rich variety of properties
attached directly to the DigitalSubject (e.g. bloodType) and use either (a)
one of a pre-defined set of Value objects (e.g. StringValue, DateValue,
etc.) if the value is simple (literal) or (b) an instance of some
Context-defined class if the value is complex/unusual.

In summary: (1) the hasAttributeStatement property is removed from
higgins.owl and instead you use whatever Context-defined property you like
and attach them directly to DigitalSubjects, and (2) for each of the
XMLSchema literal datatypes (normalizedString, date, etc) we create in
higgins.owl a corresponding class (e.g. NormalizedString, Date, etc.). These
classes all inherit from a new AttributeValue class that replaces the
current AttributeStatement class. Lastly, this replacement AttributeValue
class has, in addition to hasMetadata, a new hasValue property.

This approach allows us to use more of OWL's power in the areas related to
class and property definitions at the expense of being able to use some of
its value typing (i.e. the ability to define the range of a property)
capabilities. We gain much more than we loose.

We had earlier rejected this kind of approach because we thought that the
metadata is really about the entire "property+value statement" not about
"just the value" (which is what it looks like below). This is an interesting
philosophical point, but it appears that the practical benefits of the new
approach greatly outweigh this point, now that I'm working through your real
world requirements.

If capitalized are resources (nodes) and non-capitalized are RDF properties
then we could have as an instance of Person:

Person
bloodType
    NormalizedString
      hasValue
        "O+"
      hasMetadata
        AttributeMetadata
          source
            <RMV>
          lastModified
            <some date>
eyeColor
    NormalizedString
      hasValue
        "green"
      hasMetadata
        .etc.

Getting back to your email, this new approach will allow us to control the
cardinality of bloodType and eyeColor (your first two bullet points) using
the usual, simple OWL restrictions on the properties of Person. I'm still
working on your third bullet point.

-Paul

-----------------------------------
Jim wrote:
Paul,

Thinking more about the new ontology, I'm not understanding how a CP would
build it's own ontology where it subclasses DigitalSubject with something
like a Person class where that Person class is:
- Required to have an attribute statement which has a "bloodType" value
- Allowed to have an attribute statement which has a "eyeColor" value
- Disallowed from having attribute statements containing other values
(note that this is basically the type of thing an LDAP schema does --
defines classes and the required/optional attributes they include)

I think any subclass of DigitalSubject is allowed to have a
hasAttributeStatement property. Where the range of hasAttributeProperty is
AttributeStatement, I don't know how one would place restrictions on that
(i.e. say that hasAttributeProperty for a person may only be in the range of
something like bloodTypeAttributeStatement or eyeColorAttributeStatement.

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev