Re: MuSim Ontology problems (was Re: Share, Like Ontology)

Hi Antoine,
Hi Kurt,
Hi at all from the different lists,

Am 13.06.2010 22:13, schrieb Kurt J:
> Hi Antoine,
>
> I'm very glad to have you review my ontology - apparently it had some
> significant problems!
>
>
>> I have some comments on your ontology:
>>   1) related to OWL DL
>>   2) related to the use of owl:Class VS rdfs:Class, owl:*Property VS
>> rdf:Property
>>   3) related to musim:element, musim:subject and music:object
>>   4) related to musim:distance and musim:weight
>>
>>
>> =====
>> 1) OWL DL
>> =====
>> Are you aware that your ontology is not in OWL DL and is it intentional?
>> Please notice that minor changes would make it a DL ontology.  I can give
>> you the details if you are interested.
>>
>
> I never made a conscious decision about this one way or the other.
> I've spent some time working on it and now thing only thing that
> doesn't validate OWL DL seems to be the info about the ontology its
> self.  I get an "Untyped Individual:
> http://purl.org/ontology/similarity/"
>
> do i need to move this info to a separate doc to get OWL DL?
>
>
>
>
>> =====
>> 2) owl:Class VS rdfs:Class; owl:*Property VS rdf:Property
>> =====
>> All your classes and properties are declared using the OWL vocabulary.
>> It would be good to have, *in addition* to this, a declared type rdfs:Class
>> and rdf:Property like this:
>>
>> :Similarity a owl:Class, rdfs:Class;
>>     rdfs:label "...";
>>     rdfs:subClassOf ... etc.
>
> done, thnx!
>

I do not really understand the need for rdfs:Class:
owl:Class is already defined with rdfs:subClassOf rdfs:Class (same thing 
for the properties). So its is a transitivity issue and it depends on 
the used reasoner to resolve that issue.

>
>> =====
>> 3) musim:element, musim:subject and musim:object
>> =====
>> musim:element is defined as a FunctionalProperty which means that a given
>> thing can only have at most one element.  Moreover, music:subject and
>> music:object are subproperties of music:element, so a subject is an element
>> and an object is also an element of a thing.  Now that means that it is not
>> possible to have a subject and an object which are different.
>> The following knowledge base is inconsistent wrt you ontology:
>>
>> my:assoc :subject my:sub ;
>>          :object  my:obj .
>> my:sub owl:differentFrom my:obj .
>>
>> This contradicts the description of the properties subject and object.
>> I imagine that you want to say that an association has one subject and one
>> object.  Why not use a class restriction like:
>
> yes this is not what i meant at all!  None of these should be
> FunctionalProperty and i'm not sure why they ever were.
>
>> :Association a owl:Class, rdfs:Class ;
>>     rdfs:subClassOf [
>>         a owl:Restriction ;
>>         owl:onProperty :subject ;
>>         owl:someValuesFrom owl:Thing ]
>>     rdfs:subClassOf [
>>         a owl:Restriction ;
>>         owl:onProperty :object ;
>>         owl:someValuesFrom owl:Thing ]
>> .
>> If your data are likely to be processed by an OWL 2 RL reasoner, this would
>> not be a good solution since it is forbidden in the RL profile of OWL 2 (but
>> is allowed in EL, QL, DL and Full).
>
> actually, i have come across applications where it would be desirable
> to have one subject and multiple objects (or vice versa).  the
> restriction conceptually should be something like, "if there is a
> subject, there must be at least one object and if there is an object
> there must be at least one subject" - i'm not sure how to encode that
> so for now i'm removing all the restrictions.

Antoine's definition expresses that issue you are concerning (at least I 
think so ;) ).

>
>> Moreover, :element, :subject and :object are AsymetricProperties.  While
>> this obviously makes sense at the conceptual level, I don't think it "fits"
>> with your ontology.  Your ontology is very lightweight and little
>> constrained (which is good) except for these properties.  I don't think it
>> adds much to explicitly put such a constraint.
>
> yes now that i consider this, it makes more sense to just leave it
> unconstrained.
>
>
>> =====
>> 4) musim:distance and musim:weight
>> =====
>> I notice that you are defining two datatype properties with multiple range
>> restriction:
>>
>> :distance a owl:DatatypeProperty;
>>     rdfs:range xsd:float;
>>     rdfs:range xsd:int;
>>     rdfs:range xsd:double .
>>
>> and
>>
>> :weight a owl:DatatypeProperty;
>>     rdfs:range xsd:float;
>>     rdfs:range xsd:int;
>>     rdfs:range xsd:double .
>>
>> I'm quite sure that it is not what you intend to mean and I imagine that you
>> would like to say that the weight or the distance can be either a float, a
>> double or an int.  Here you actually specify that the distance and the
>> weight of something is necessarily a float, a int and a double at the same
>> time.
>>
>> Furthermore, the OWL spec [1] says that:
>>
>> """As specified in XML Schema [XML Schema Datatypes], the value spaces of
>> xsd:double, xsd:float, and xsd:decimal are pairwise disjoint."""
>>
>> This implies that :distance and :weight are in fact empty relations since it
>> is impossible to have a value which is both a float and a double.  Using
>> :distance or :weight in the predicate position of any triple would make the
>> knowledge base inconsistent.
>>
>> If you want to say that a distance or weight has to be in *one of* the three
>> datatypes, you should rather say:
>>
>> :weight a owl:DatatypeProperty, rdf:Property;
>>     rdfs:range [ owl:unionOf ( xsd:float xsd:int xsd:double ) ] .
>>
>> However, I feel unsatisfied by this because it is slightly overconstraining.
>>   Why not allow xsd:decimal or even owl:real as well? Or untyped literals
>> such as:
>>
>> ex:a :distance "1879.42" .
>>
>> I imagine that the value for such a distance will be computed automatically
>> and the programme which does it will ensure that it is indeed a number.
>>
>
> another rookie mistake i'm afraid!  i think leaving the rdfs: range
> unspecified perhaps makes the most sense - yes it is a common
> occurence to get a "NaN" distance in audio signal based similarity and
> other similarity calculations.

Here the issue is that the programme, which computes the number, knows 
of course that it is a number, but the reason to define it at least as a 
kind of number is for reusing this values.
I'm somehow satisfied with the restriction rdfs:range [ owl:unionOf ( 
xsd:float xsd:int xsd:double ) ], because it is a well-defined range, 
which expresses that the values are number. I can't really imagine other 
values that are might used here. The XSD namespace is a kind of best 
practice for defining the Datatypes.

Cheers,

Bob

>
> thanks for all the input - I'm a bit embarrassed i've made so many
> mistakes!  But i'm very keen to get it correct.
>
> Please find a brief change log here:
>
> http://grasstunes.net/ontology/similarity/0.2/musim.html#changes
>
> I hope to seriously update the ontology spec soon so it's more concise
> and useful.  Thanks again!
>
> -Kurt J
>

Received on Monday, 14 June 2010 14:35:08 UTC