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
