Re: ISSUE-65 (excess vocab): REPORTED: excessive duplication of vocabulary

Le me be clear, I didn't agree I liked this solution, I agreed it was  
the minimal solution under current constraints :-)
What I do agree with Boris on is that I see no reason to allow  
punning of object and datatype properties - these are inherently  
different than the class/instance punning, which is based on a known  
KR feature (metamodeling - which got its own WG Note from the  
dissemination SWBPD WG).  Again, I've yet to see any use case where  
this kind of punning is useful - I have seen some in some advanced KR  
systems where morphing from one to the other is doable, but I don't  
see us taking OWL anywhere near that far into pi-logic space.

On Nov 21, 2007, at 4:31 AM, Boris Motik wrote:

>
> Hello,
>
> I do agree that duplication of vocabulary is rather nasty. I've  
> spoken to Jim Hendler at ISWC about it, and we came to a possible
> solution, which I'd like to overview next. Before giving the  
> solution, however, let me just recapitulate why we introduced the
> duplicated vocabulary in the first place.
>
> 1. OWL 1.1 allows the same URI to be used as both an object and as  
> a data property. (OWL 1.1 in general allows for punning; however,
> for this particular problem, only punning on object and data  
> properties is a problem. Thus, let us not discuss here the general
> problems of punning in OWL 1.1 - this should be discussed separately.)
>
> 2. Parsing OWL RDF is difficult: one needs to first scan the file  
> for the appropriate rdf:type triples, after which one needs a
> second pass to actually output the axioms. Assuming that you parse  
> just one ontology, this is a pain but not a serious problem;
> however, ontology imports exacerbate this problem. Assume that you  
> are parsing an ontology O that imports an ontology O'.
> Furthermore, let us assume that O contains, for example, a  
> someValuesFrom restriction on the property p. In OWL 1.0 it can happen
> that the triples in O do not allow us to disambiguate the type of  
> p; thus, we need to look at the imported ontology O' to find out
> what the correct type of p is. This makes parsing of OWL RDF really  
> difficult: you can't process an ontology by itself, but you need
> to look at the imported ontologies as well.
>
> Even worse, what if the imported ontology O' is not in OWL RDF but  
> in some other format? (For example, KAON2 allows a file ontology
> to import an ontology that resides in a relational database.)  
> Parsing is now next to impossible. Thus, to allow parsing an ontology
> O by looking only at the triples in O, we introduced the typed  
> vocabulary.
>
>
> ---------------------------------------------------------------
>
> And now for the solution.
>
> I do agree that the first point is not really a use-case: I do not  
> expect that users will actually want to use the same URI as both
> an object and a data property. In contrast, being able to parse  
> each ontology by itself seems like a desirable property that should
> be preserved. Hence, I propose to change the specs as follows:
>
> 1. I would leave the structural specification as it is. In this  
> spec, I would allow the same URI to be used as both an object and a
> data property, and I would leave the typed vocabulary as it is.  
> This is not so much driven by the desire for punning; rather, the
> structural specification is intended to provide guidance for  
> implementors of OWL APIs. In all APIs I know of, you do have a
> separation of object and data properties; therefore, we should keep  
> this separation in the spec as well. Whether you then allow the
> same URI to be used as an object and as a data property is then  
> really irrelevant for all intents and purposes.
>
> 2. A transformation of an ontology from the structural format  
> (i.e., from the functional-style syntax) into RDF should be possible
> only if you strictly separate the properties into object and data  
> ones.
>
> 3. The transformation into RDF would then be roughly the same as in  
> OWL 1.0, with the following difference: the resulting RDF graph
> would be *required* to type all properties used in the graph.
>
> 4. An RDF graph G could be parsed into the structural format only  
> if each URI that is used as a property is correctly typed IN THIS
> GRAPH. If, for example, some URI p is used in a someValuesFrom  
> restriction but G contains neither <p rdf:type owl:ObjectProperty>
> nor <p rdf:type owl:DatatypeProperty>, then G would not constitute  
> a valid OWL 1.1 DL ontology.
>
>
> This solution seems to have the benefit of satisfying everyone: we  
> can parse each RDF graph by itself, there is no typed vocabulary,
> and most reasonable use cases seem to be satisfied. Let me know how  
> you feel about this solution.
>
> Regards,
>
> 	Boris
>
>
>> -----Original Message-----
>> From: public-owl-wg-request@w3.org [mailto:public-owl-wg- 
>> request@w3.org] On Behalf Of OWL Working
>> Group Issue Tracker
>> Sent: 20 November 2007 14:49
>> To: public-owl-wg@w3.org
>> Subject: ISSUE-65 (excess vocab): REPORTED: excessive duplication  
>> of vocabulary
>>
>>
>>
>> ISSUE-65 (excess vocab): REPORTED: excessive duplication of  
>> vocabulary
>>
>> http://www.w3.org/2007/OWL/tracker/issues/
>>
>> Raised by: Jeremy Carroll
>> On product:
>>
>>
>> The member submission documents seem to replace a good many  
>> properties from OWL 1.0 with three
>> properties in OWL 1.1. (The old version, and two new versions, one  
>> for data properties, and one for
>> object properties)
>>
>> This:
>> - creates additional work for implementors
>> - creates additional work for documentation writers
>> - potentially creates confusion for people as they learn the language
>>
>> Do the benefits outweight these (and other) costs?
>>
>>
>>
>>
>>
>
>
>

"If we knew what we were doing, it wouldn't be called research, would  
it?." - Albert Einstein

Prof James Hendler				http://www.cs.rpi.edu/~hendler
Tetherless World Constellation Chair
Computer Science Dept
Rensselaer Polytechnic Institute, Troy NY 12180

Received on Wednesday, 21 November 2007 19:03:20 UTC