RE: [OPEN] and/or [PORT] : a practical question

It seems many of us are reaching consensus on avoiding judgments (good/bad) and concentrating on consequences of decisions and tradeoffs. However, we must not go to far in this.  Tradeoffs by definition mean you can't have it all. Some consequences are clearly of the sort: "you probably don't want to do that, and here is why".  In our recommdations, we don't want to appear so neutral that a reader can't work out for themself how to choose among the defining 'consequences'.  Some will be able to work out for themselves whether a consequence is what they want or not, in other cases, they will need advice from us.  

I'm agnostic on how often this would be the case, Jim would say relatively rarely, that is beside the point I am making here.

MIke

 -----Original Message-----
From: 	public-swbp-wg-request@w3.org [mailto:public-swbp-wg-request@w3.org]  On Behalf Of Deborah L. McGuinness
Sent:	Tuesday, March 30, 2004 5:03 PM
To:	Natasha Noy
Cc:	Aldo Gangemi; Ian Horrocks; Guus Schreiber; SWBPD list; Nicola Guarino; claudio.masolo@ladseb.pd.cnr.it
Subject:	Re: [OPEN] and/or [PORT] : a practical question


i support the position that in our documents we should be clear about:
stating options   AND
stating implications of taking an option  (and adding more prose if 
necessary to help people understand the tradeoffs involved).

Knowing how you are going to use an ontology when one creates the 
initial model is important and that impacts how i do a lot of my modeling.
If i am modeling for use with a reasoner - and note - that could be with 
non-dl reasoners but may be with other logical reasoners, i make sure i 
have as much information as possible represented in constructs that are 
first class objects and have clear semantics.  Many times this is not 
the case with meta information so I typically avoid putting anything in 
meta classes that i want to reason with.

i would however make updates to the information in the included message 
below that makes it sound like one only avoids meta classes if one is 
trying to do dl reasoning. 
a possible restatement is that having information modeled using 
constructs with unambiguous semantics that are first class objects in 
the modeling system facilitates integration with theorem provers.  (the 
theorem provers may be fol reasoners that want to utilize the semantics 
of the underlying logic for their reasoning and they could be dl 
reasoners that are presumably used for their computational efficiency.

There are many things that i end up taking into account when i design an 
ontology including at least:
what kind of reasoning i may do with the ontology
who will maintain the ontology  (if i have a staff of high school kids 
or one phd in kr radically changes how i model things)
what other applications am i interacting with
what background do my users/maintainers have - sometimes different 
equivalent models are more natural for one type of user over another
etc.

i expect we will have sections including many of these issues  and we 
will probably make progress more quickly and come to consensus faster if 
we just
present options, implications, and tradeoffs and try to stay away from 
judgements either way.

Deborah




Natasha Noy wrote:

>
> At 7:54 PM +0100 3/27/04, Aldo Gangemi wrote:
>
>>
>> My two cents ...
>
>
> [snipping eighteen cents...]
>
>> Bottom-line: let Natasha, Bernard, or anyone else produce cases of 
>> reasonable use of metaclasses, and let's try to find an alternative 
>> way to model them. If that way is unnecessarily complicated for the 
>> use case we are considering, then we can consider that use an example 
>> of best annotation practice.
>
>
>
> Aldo, your bottom line assumes that it is _always_ better to avoid 
> using metaclasses if there is a somewhat reasonable (but perhaps less 
> intuitive, more cumbersome, but not overly so) way to represent the 
> same thing without them. I think it is a strong assumption to make and 
> using it as an imperative for best practices is even a stronger (and 
> more dangerous) thing to do. It is already clear from the discussion 
> that there is no consensus in the community. Given that, instead of 
> trying to produce  documents that say "avoid metaclasses if at all 
> possible", we should just acknowledge the different approaches and 
> describe them. Then people can choose.
>
> There should  be a "presumption of innocence" of any construct that is 
> valid in the language. Sure, there are trade-offs. There are examples 
> when using metaclasses allows for a simpler and more intuitive model 
> or for easier use in application (e.g., some knowledge-acquisition 
> applications; not all applications and reasoners on the SW are going 
> to be DL reasoners). At the same time, you loose the ability to have a 
> DL reasoner to use that information. And we should document that too 
> and show ways to do it differently so that the ontology is in OWL DL, 
> if that's what one needs.
>
> As an aside, I must say that in my interactions with Protege users, 
> many of those who use OWL for modeling, do it simply because it is a 
> standard and never think or plan to invoke a classifier (or define any 
> necessary and sufficient conditions; just necessary conditions).
>
>> IMO, it remains to be demonstrated that there exists a case in which 
>> a reasoner must be able to reason on classes and metaclasses in the 
>> same problem space, without alternative solutions.
>
>
> Again, this assumes that, for all reasoning services, it is always 
> best to avoid metaclasses. As many have pointed out already, we don't 
> have enough experience to know what kind of modeling would work on the 
> SW. More important, we don't have enough real SW applications to know 
> what kind of reasoning will be most pervasive and useful on the SW. If 
> we try to optimize the modeling for a particular single kind of 
> reasoning (e.g., DL reasoning), we may shoot ourselves in the foot by 
> encouraging people to produce ontologies that real-world SW reasoners 
> won't be able to use productively. I am all for Pat's humility stance.
>
> Natasha
>

-- 
 Deborah L. McGuinness 
 Associate Director Knowledge Systems Laboratory 
 Gates Computer Science Building, 2A Room 241 
 Stanford University, Stanford, CA 94305-9020 
 email: dlm@ksl.stanford.edu
 URL: http://ksl.stanford.edu/people/dlm
 (voice) 650 723 9770    (stanford fax) 650 725 5850   (computer fax)  801 705 0941

Received on Wednesday, 31 March 2004 00:26:57 UTC