W3C home > Mailing lists > Public > semantic-web@w3.org > June 2010

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

From: Kurt J <kurtjx@gmail.com>
Date: Sun, 13 Jun 2010 15:13:20 -0500
Message-ID: <AANLkTilPtosac4YWAANsJ7Y-jwDbLEeL_7nuk-DdgjsD@mail.gmail.com>
To: Antoine Zimmermann <antoine.zimmermann@deri.org>
Cc: Linked Data community <public-lod@w3.org>, Semantic Web <semantic-web@w3.org>, pedantic-web@googlegroups.com
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:

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!

> =====
> 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.

> 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

> =====
> 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.

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:


I hope to seriously update the ontology spec soon so it's more concise
and useful.  Thanks again!

-Kurt J
Received on Sunday, 13 June 2010 20:13:54 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:45:18 UTC