- From: Rhys Lewis <rhys@volantis.com>
- Date: Thu, 1 Nov 2007 01:53:55 -0600 (MDT)
- To: "'Diego Berrueta'" <diego.berrueta@fundacionctic.org>
- Cc: "'JOSE MANUEL CANTERA FONSECA'" <jmcf@tid.es>, <public-uwa@w3.org>, <public-ddwg@w3.org>, <mymobileweb-celtic-es@lists.morfeo-project.org>
Hi Diego, Um, I don't disagree with any of what you have written. That's why the current ontology uses an annotation property to reference an instance outside the domain of the characteristics! You've described the benefits of the current ontology structure! The only difference is that the annotations are grouped in the current ontology. This reduces the coupling between a class or a property and its alternate names because there is only ONE annotation property involved. Jose's proposal requires at least 3 annotation properties for each property and each class in the current ontology. For simple properties, Joses scheme means there will be three times as many defintions for the alternate names of a property as for the property itself! Now, if you can give me an example of a current tool that uses particular annotation properties in a way that is the same as they are used in the ontology, but using Jose's proposal, that would be good evidence of a benefit for the change. I'm not aware of any. I think you are saying that the SPARQL queries would be marginally simpler in Joses approach. OK, but why are the alternate names of interest? The current names are those that can be used to, for example, name a Java variable, or a JavaScript variable that contains that property. Is that really of interest to your queries? Surely, you are going to be more interested in queries that retrieve the correct property based on the name in the MWI DD vocabulary? That is NOT the purpose of the current annotations. It was once, but with the divergence in structure of the DD vocabulary and the ontology, this no longer makes sense. Indeed, it could be argued that names for specific vocabuaries have no place in the ontology. Rather, the DD vocabulary should define its names and simply refer to the appropriate entries in the ontology for the 'formal' defintions. It would be helpful if you could clarify why you are interested in the alternate names, and what purpose you see them fulfiling? Perhaps I'm missing something. I was getting to the point of proposing removing them as having no value. They are a huge maintenance overhead too. Best wishes Rhys > -----Original Message----- > From: Diego Berrueta [mailto:diego.berrueta@fundacionctic.org] > Sent: 31 October 2007 16:23 > To: Rhys Lewis > Cc: 'JOSE MANUEL CANTERA FONSECA'; public-uwa@w3.org; > public-ddwg@w3.org; mymobileweb-celtic-es@lists.morfeo-project.org > Subject: Re: [Mymobileweb-celtic-es] RE: Comments on the > current version ofthe ontology > > 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 Thursday, 1 November 2007 07:54:12 UTC