Re: How burdensome are the OWL restrictions on metadata?

Hi Jim,

Thanks for your quick reply.  Your description is exactly as I had 
feared.

However, as any semi-practical person knows, attaching data to classes
and properties has absolutely no effect on the complexity class of the
ontology if that data isn't used in conjunction with the rest of the 
ontology.
And of course, in ordinary usage, the data attached to classes and 
properties
isn't used at all in inference, its just read by attached procedures.  
My guess
is that if the major OWL architects had been more tuned in
to ordinary practice, they would have devised a set of rules saying 
"Yes, its
OK to use metadata as long as you stay within certain boundaries."  For 
example,
suppose properties with domain class or domain property are restricted 
to
have range a subclass of literal.  Would that restriction keep the 
complexity
of OWL-DL within bounds? (I don't happen to know).  That would be ugly,
but not more ugly than the owl:ObjectProperty/owl:DatatypeProperty hack.

Your DL book recommended using a extralogical "distinguished instance" 
hook to
get the desired effect.   Not only is that contrary to the whole point 
of knowledge-based
programming, but it probably encourages people to violate the dictum 
that URI's
are supposed to be opaque.  I haven't been able to think of a way to 
achieve the
desired effect without looking inside of URI's, can you?
The necessary hacks would probably permeate quite a bit of code.  For 
example,
when we use Protege as our KA tool, the metadata shows right up 
attached to
the classes and properties.  Editing that data is VERY convenient.
If we used the suggested "hook", none of the data would
have been visible, unless we hacked the Protege source code.

I take this as a strong indicator that the principal OWL architects did 
not
bother with a requirements analysis before deciding on what to add and
what not to.  For example, attaching lexemes to classes/concepts seems 
to
be a common, if not ubiquitous, practice among natural language 
processing
systems.  Apparently all of the ontologies for these systems classify 
as OWL-full.
I'm wondering if the huge body of Protege users were polled by the 
committee
to see if they attach data to classes or slots.
But of course, the bulk of the DL designers and I have never seen
eye-to-eye (I say designers, since there is a legion of DL users that
appear to be quite happy with my viewpoint).

This is indeed a set-back for the Semantic Web.
My hope is that RULE-ML is a bit more generous in its outlook (I
haven't been paying close attention yet).

Cheers, Bob

On Friday, April 4, 2003, at 01:05 PM, Jim Hendler wrote:

> At 11:11 -0800 4/4/03, Bob MacGregor wrote:
>> Our applications like to associate icons (gifs) with some
>> classes.  We implement this by having a class  IconClass that
>> is a subclass of rdfs:Class that has a slot 'hasIcon'.  For example:
>>
>>     system:IconClass rdfs:subClassOf  rdfs:Class
>>     rdfs:domain system:hasIcon system:IconClass
>>     rdfs:range system:hasIcon xsd:string
>>     chime:Aircraft rdfs:subClassOf  system:IconClass
>>     chime:Aircraft  system:hasIcon "htttp:/localhost/.../aircraft.gif"
>>
>> My question is, suppose we add some statements that include
>> some simple OWL-lite properties.  Does the combination of
>> our meta-level statements and the OWL-lite statements land
>> us into OWL-full, or are we OK?
>>
>> Cheers, Bob
>
> welcome to OWL Full.  That said, there are some well know tricks for 
> dealing iwth this, in particular to create a distinguished instance 
> associated with each class - the problem is you must use an 
> "extralogical" trick for managing these, as they cannot be directly 
> associated with the class -- in some of the OWL Lite ontologies we've 
> done, we create a FooData class for every class Foo (with one instance 
> which is the "noninherited properties" as they would be in LOOM), and 
> then just have our tools know about that.  The OWL design requires a 
> strict separation of datatype and objectType which is, in practice, 
> one of the main differences between OWL Lite/DL and OWL Full.  If we'd 
> decided to include some standard mechanism in the OWL design for this, 
> I think we would have been better off (i.e. almost every real world 
> system needs some way to put some kind of property on each class for 
> managing things) - but there was no consensus in the group as to how 
> and whether to do this, so it didn't make it into the langauge.  My 
> group ended up going through a bunch of the papers to appear in the DL 
> Handbook, and discovered this distinguished instance trick - so that's 
> what we are using.
>  -JH
> p.s. to see this used in practice, see 
> http://www.mindswap.org/2003/CancerOntology/ which is in (nearly 
> correct) Owl Lite - needs a couple minor fixes to conform to last 
> minute WG changes.  It is the largest OWL Lite (and possibly largest 
> DAML or OWL) ontology composed to date - and it uses this trick 
> because each class needs to have a lot of individual/non-inherited 
> properties attached to it.
> -- 
> Professor James Hendler				  hendler@cs.umd.edu
> Director, Semantic Web and Agent Technologies	  301-405-2696
> Maryland Information and Network Dynamics Lab.	  301-405-6707 (Fax)
> Univ of Maryland, College Park, MD 20742	  240-731-3822 (Cell)
> http://www.cs.umd.edu/users/hendler