- From: Jim Hendler <hendler@cs.rpi.edu>
- Date: Wed, 21 Nov 2007 14:03:03 -0500
- To: Boris Motik <boris.motik@comlab.ox.ac.uk>
- Cc: "'OWL Working Group WG'" <public-owl-wg@w3.org>
- Message-Id: <AFFA1D7A-5FB8-4780-B858-E7ED7C5E3F6E@cs.rpi.edu>
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