| RE: [higgins-dev] Higgins Ontology Version |
|
Yeah, this is one approach Tom and I were discussing yesterday. We also noticed the way the OWL language guide was using intersectionOf seemed vaguely promising, but I haven't looked into that much more. It looked like one could say a Person class is the intersection of a DigitalSubject and a certain type of property (or properties).
Jim
>>> "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 |