- From: Evren Sirin <evren@cs.umd.edu>
- Date: Sat, 24 Jul 2004 13:29:05 -0400
- To: David Martin <martin@AI.SRI.COM>
- Cc: zze-VALLEE Mathieu RD-TECH-GRE <mathieu.vallee@rd.francetelecom.com>, public-sws-ig@w3.org
David Martin wrote: >> Is there a special reason not to repeat the domain (apart from avoiding >> redundancy) ? > > > Not to my knowledge; that is, it's just to avoid redundancy. > >> When I edit services using Protege (and OWL plugin), it seems that I >> must add the domain for hasInput and hasOutput properties. If not, >> Protege only allows me to use the hasParameter property (it does not >> include reasoning to deduce this kind of domain inheritance). > > > It's a good point. This is not the first time that a tool-building > consideration may lead us to alter our notions of what is good style. > > In the 1.1 Beta release (just about ready to be announced) I'm going > to go ahead and add the domain explicitly for the benefit of tools > (not everywhere, but in the crucial IOPE properties).. But this is > somewhat provisional; that is, if there are any important objections > then it's possible these declarations will be removed. I'm not aginst these domain restrictions being added but it is hard to decide which ones should be added and which ones not. This is not an OWL-S specific issue and it seems that the tool needs to be updated not the ontology. I believe if a request is made, this feature can easily be added to Protege. As a side note, the ontology browser/editor SWOOP [1] we have developed at Mindswap would already show these kind of inheritances on domain and range. If you download the latest release you need to set the reasoner to Pellet to see this effect, if you download the nightly-build of SWOOP the default RDF-S reasoner should also display the same information. Regards, Evren [1] http://www.mindswap.org/2004/SWOOP/ > > Regards, > David Martin > >> However, this kind of troubles may be solved by the (future) OWL-S >> editor :-) >> >> Regards, >> Mathieu > > > >
Received on Saturday, 24 July 2004 13:29:50 UTC