- 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
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 DL-level). * 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. Regards, -- 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 www.fundacionctic.org
Received on Wednesday, 31 October 2007 17:11:27 UTC