W3C home > Mailing lists > Public > public-ddwg@w3.org > October 2007

Re: [Mymobileweb-celtic-es] RE: Comments on the current version of the ontology

From: Diego Berrueta <diego.berrueta@fundacionctic.org>
Date: Wed, 31 Oct 2007 17:23:28 +0100
To: Rhys Lewis <rhys@volantis.com>
Cc: 'JOSE MANUEL CANTERA FONSECA' <jmcf@tid.es>, public-uwa@w3.org, public-ddwg@w3.org, mymobileweb-celtic-es@lists.morfeo-project.org
Message-Id: <1193847808.5052.83.camel@duncan.fundacionctic.org>

Hi Rhys,

I support all of Jose's proposals. Find below my arguments for the use
of annotation properties to provide the alternateNames of the concepts
and properties of the ontology:

El dom, 14-10-2007 a las 04:20 -0600, Rhys Lewis escribió:
> > * During our discussion on August 16th [2] based on [3] I
> > agreed on providing alternative ways of providing
> > alternateNames to the properties. I have done that. You can
> > see the example on the attached OWL file for the property
> > supportedNetworkBearers with has two annotation properties
> > for the alternative ways of referring to it.
> I can see your propsed mechanism. Since the changes will cause significant
> disruption to the ontology, and to the code to extract the document, I'd
> like to understand why you think this is a better approach. Can you
> explain for me? There seems to be no advantage that I can see to doing it
> this way
> over the current approach. To me the current approach introduces less
> coupling too.

Why we should use annotation properties to provide the alternate names? 

* Because annotation properties were designed precisely for this
purpose, to annotate the concepts in the ontology.

* Because third-party applications expect to find annotations in the
concepts, particularly regarding the concept name and alternate names.

* Because alternate names are not part of the domain. They're just
complementary linguistic information, like a thesaurus. They aren't
useful for a reasoner, nor they are of any use to infer new information
nor to check the correctness of the ontology.

* Because annotation properties don't compromise the logical level of
the ontology (i.e.: they are safe to use, even if you want to be in the

* Because if we don't use annotation properties, we have to introduce a
new class which doesn't belong to the domain (in this case,
Alternate_Names) and a collection of instances which don't have any
meaning in the domain. They're just auxiliary modeling resources.

* Because if we use the instances of Alternate_Names, it is a bit more
complex to write (SPARQL) queries to get the name of a concept.

* Because if we use the instances of Alternate_Names, we have to link
them to the concepts in the ontology using... annotation properties!
Note, however, that there is a pre-defined annotation property to link a
concept to its name as a literal (rdfs:label), but there isn't any
pre-defined annotation property to link a concept to a different
instance that indicates its name (to the best of my understanding,
rdfs:seeAlso has a slightly different semantics).

* Because it isn't hard to change the ontology to use annotation
properties. Actually, this can be done with a few SPARQL queries, see
the following template (in this example, :newAnnotationProperty is the
new annotation property as per Jose's suggestion):

  CONSTRUCT ?x :newAnnotationProperty ?nameLiteral
  WHERE { ?x rdfs:seeAlso ?altName .
          ?altName rdf:type :Alternate_Names .
          ?altName :camelCaseName ?nameLiteral }

I my opinion, annotation properties don't introduce any kind of
coupling. Can you expand on why do you think Jose's proposal introduces
more coupling than the current ontology?

I acknowledge the issue with the Protege plugin that generates the
documentation, but I assume this plugin can be easily adapted to work
with Jose's proposed schema.


Diego Berrueta
R&D Department  -  CTIC Foundation
E-mail: diego.berrueta@fundacionctic.org
Phone: +34 984 29 12 12
Parque Científico Tecnológico Gijón-Asturias-Spain
Received on Wednesday, 31 October 2007 17:11:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:00:15 UTC