| [higgins-dev] RE: Higgins ontology questions |
Valery wrote: > > Hi Paul, > [snip] > > My understanding of attribute was that it should satisfy with the > following three requirements: > > 1. An attribute should be the object property > (http://www.w3.org/2002/07/owl#ObjectProperty). > 2. An attribute should be sub-property of the attribute property > (http://www.eclipse.org/higgins/ontologies/2006/higgins#attribute). > 3. The range of an attribute should be a either the attribute class itself > (http://www.eclipse.org/higgins/ontologies/2006/higgins#Attribute) or > one of its descendants. Yes. > > If my understanding is correct then there is no any problem with > "test-person.owl" but none of properties declared in > "person-with-address.owl" is an attribute. Ah, this is a bug. I have just checked in these two changes: postalAdress -> postalAddress; postalAddress is now a sub-property of higgins:attribute > > When I looking at "firstname" and "surname" properties there I see > that both are object properties (1) and they are ranged by > "NormalizedStringSimpleAttribute" (3) but... none of them are > sub-properties of attribute property (2). Why? Did you just forget to > declare both of them as sub-property of the attribute? Yes. I forgot these too. Thanks. I've just checked in this fix too (see attached .psf) > > In my opinion in your example "PostalAddress" class should be a > sub-class of ComplexAttribute class A third bug! PostalAddress should have been a sub-class of ComplexAttribute. I've made this bug fix and checked it in too. > ...but ComplexAttribute class should > be modified in order to do so. > > Please note that "complexValue" property of "ComplexAttribute" class > was replaced by the "attribute" property in the higgins.owl schema. > > I think that in such way it will be more clear what an attribute really > is and we just can say that complex attribute is an attribute which > contains another attributes as values. This suggestion of yours that ComplexAttribute is recursively defined is interesting. Jim raised related issues on the list today. The benefits of the current approach are that the higgins:complexValue property can point to a precisely defined complex data structure whose sub-parts (classes) and relations (properties) can be cleanly and simply defined using std. OWL constructs. This will allow reuse of existing ontologies of complex objects developed by anybody. The benefits of the "recursive" approach you propose is that it allows each sub-part of a complex object to have its own metadata. I am trying to imagine the need for this power, but at the moment I only see the foggy outlines of real-world use cases. The downside of this approach is that you force each sub-part of the complex object to be defined using our "heavy" higgins:Attribute and higgins:attribute constructs. This means we will *not* be able to reuse existing complex object ontologies from the outside world. It also means that defining these complex objects is more complicated. In summary we might need both approaches. I am more convinced of the current approach than the one you are suggesting. But a few good real-world uses cases would tip me over. It wouldn't be hard to accommodate both approaches if we choose to. -Paul
Attachment:
ont.psf
Description: Binary data