W3C home > Mailing lists > Public > public-owl-wg@w3.org > January 2008

Specifically on ISSUE-65 (Re: Punning, typed vocabulary, and handling RDF graphs (and ISSUE-65))

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Thu, 10 Jan 2008 12:58:50 +0000
Message-Id: <5725C490-0762-4BEB-86C8-A9F23582C0B7@cs.man.ac.uk>
To: "Web Ontology Language ((OWL)) Working Group WG" <public-owl-wg@w3.org>

ISSUE-65 reads as "excessive duplication of vocabulary" and  

"""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)"""

But now I realize that I don't understand this. In particular I don't  
understand how this is supposed to be an issue against the RDF  
serialization. What properties are duplicated? How many is a "good  
many"? I see some "Classes" duplicated (e.g., ObjectRestriction and  
DataRestriction), but someValueFrom is someValuesFrom. maxCardinality  
is maxCardinality.

In the *structural specification* there are typed quantifiers, but  
the quantifiers are not "properties" in the functional syntax.  
Jeremy, could you clarify the degree of excess and whether you were  
complaining about the functional syntax or the rdf serialization?

(In general, there's a choice in the functional syntax between  
disambiguating by typing the constuctor or the arguments, e.g., either:

(1)	DataPropertyDomain(:someProperty, :SomeDatatype)

Is unambiguous, but so is:
(2)	Domain(DataProperty(:someProperty), Datatype(:SomeDatatype))

I think in the functional syntax I prefer the former (for writing). I  
think in the xml syntax we ended up with *both*. Ah yes:

	        <ObjectProperty owl11xml:URI="#eats"/>
       			<ObjectProperty owl11xml:URI="#eaten_by"/>

But that's not necessary, You could eliminate the typed quantifiers:
	        <ObjectProperty owl11xml:URI="#eats"/>
       			<ObjectProperty owl11xml:URI="#eaten_by"/>

Received on Thursday, 10 January 2008 12:59:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:42:02 UTC