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

Aldo Gangemi writes 

>I agree, from my experience most uses of metaclasses result from insufficient
>domain analysis. I think that insufficient 
>analysis is responsible for many other 
>simplifications, even in the use of the subClass 
>relation or in the representation of qualities in 
> flat value spaces (cf. Guus' message).

>Low-detailed domain analysis is sometimes due to 
> a desire of economicity,

Hello,


The Question (i prefer question than problem) of uses of metaclasses in the analysis phase 
is an old one and it's not a SW specific topic.

A lot of litterature has been produced during years on this topic but :
	- the question seems to be still opened 
	- i'm pretty sure that analysts/programmers all around the world will continue to use classes as instances 
	For these points i ask myself the question : why people continue to uses classes as instances despite of all this litterature, concrete examples, good arguments ?
		- perhpas because it is important in their context and that it is the only solution,the good one to solve their problem. After all, who can pretend to know all the problems in the world and for each what is the good way to solve (describe) them,
		- perhaps because, even if we can prove that it's a wrong way, Aldo, Ian and all the members of this group (except me) are experts and most of people are not.

	- "a desire of economicity" : this desire is each day more irrepressible in some contexts
	

So, why this group would be more successfull in the task of discovering THE magic formula to express general rules in such a way that in front of an analysis problem at least 80% of analysts  will clearly and quickly understand that what they do is wrong? 

Perhaps that one good thing to do (among other of course), as it has been pointed out by other people in this WG, would be to have a list of concrete points both "real world storytelling" based  (cf.Dan Brickley) and theorically based. This list could be structured like this :


		Introduction :

		 What you can find in these Guide that you can't find in an user manual, a Tutorial, an Academical Course, a High level methodology for the building of KB,.... : 
			
				- A list of well known and critical (from our point of view) decision points in a SW project lifecycle for which, we think that knowing the exact consequences of the choices you can do, can be very fruitful for you .
				All the following points have been already experimented in real project or are direct consequences of the nature of the tools you use. 


	Analysis phase : 

		"Point xxx : using classes as instances is not a wrong way in its own but BE CAREFUL if you really  want or need to use this "style" here are the known problem you can (are sure to) encounter :
			- some reasoning problem : for example if you intend to use your ontology/documents or annotations to do some classification tasks....
			- some interoperability problems :

		To help you ,here are some well known examples where there is a way to avoid the use of classes as instances : 
				1) Design pattern1
				2) Design pattern 2

		Point yyy : defining more than n level of subclassing is not a wrong way in its own but BE CAREFUL if you really  want or need to use this "style" here are the known problem you can (are sure to) encounter :
			......

			To help you here are some well known examples where there is a way to translate a n-depth-level Ontology in a m-level-Ontology (m<n) : 
				1) Design pattern1
				2) Design pattern 2

		Point zzz : There is potentially no limit in the number of classes you can define in an Ontology but BE CAREFUL if you really  want or need to use this "style" here are the known problem you can (are sure to) encounter :

			.....
			To help you here are some all ready experimented solutions to split an Ontology which have been used with succes :
				1) Example 1 :
					Context :
					Initial Ontology :
					result :
							Benefits :
							loss : 

Perhaps that we could define a thematic index to help a reader to explore the list of points. 

		Analysis Phase :
			Pefomance points :
				Point x, Point y, Point z
			Interoperability points :
				Point x, point n
			Reasonning points
				Point y, Point m
			Versioning Points
		Implementation Phase :
			Pefomance points :
				Point a, Point y, Point b
				.....

			
Thank you 

Best regards 

Marco NANNI

-----Message d'origine-----
De : public-swbp-wg-request@w3.org
[mailto:public-swbp-wg-request@w3.org]De la part de Aldo Gangemi
Envoyé : samedi 27 mars 2004 19:55
À : Ian Horrocks
Cc : Guus Schreiber; SWBPD list; Nicola Guarino;
claudio.masolo@ladseb.pd.cnr.it
Objet : Re: [OPEN] and/or [PORT] : a practical question



My two cents ...

At 12:57 +0000 27-03-2004, Ian Horrocks wrote:
>On March 26, Guus Schreiber writes:
>>  Ian Horrocks wrote:
>
>[snip]
>
>>  After reading this I was about to put my chai hat off and send a flame.
>>  But it generated such well-founded responses that I want to thank for
>>  starting this dialectic debate.
>
>Glad to be of service.
>
>Perhaps I could push things along a bit further by refining my initial
>contention vis-a-vis meta classes.
>
>Regarding correctness of usage, I speak as I find. I have had the
>discussion on numerous occasions, and have almost always found that
>suggested requirement examples are "ill conceived". Examples include
>four-engined-aeroplane as a meta-class, with Boeing-747 being an
>instance (this came up at one of the WebOnt f2f meetings), an instance
>of the patient class who is related via an instance of the "takesDrug"
>property to the class "Aspirin" (I think that this may also have come
>from a WebOnt f2f meeting) and "Boeing" as a subClass of aeroplane and
>an instance of Company (this came up at a talk at WWW in
>Budapest). Note that these examples were carefully crafted by KR
>experts to illustrate the requirement for meta-classes. In all cases
>it was subsequently agreed, even by the proposers, that these are
>examples of poor modelling, i.e., they didn't capture the intended
>meaning of the modeller (Boeing-747 is better modelled as a subClass
>of four-engined-aeroplane, the patient should take an instance of
>Aspirin, and the two Boeings are just different objects).

I agree, from my experience most uses of metaclasses result from insufficient
domain analysis. I think that insufficient 
analysis is responsible for many other 
simplifications, even in the use of the subClass 
relation or in the representation of qualities in 
flat value spaces (cf. Guus' message).

Low-detailed domain analysis is sometimes due to 
a desire of economicity, for example if we want 
to talk about legal regulations in the domain of 
navigation, two or three colors might even happen 
to fall into the discussion, but a complete color 
hierarchy is useless. Similarly, if we talk of 
fishery commodities (only), having a complete 
taxonomy of aquatic organisms paired to a 
taxonomy of ways of post-harvesting those 
organism, and to a taxonomy of packaging them, 
can be overspecified, and a simple taxonomy of 
commodities fits perfectly the task.

But often economicity leads to underspecification 
wrt to the task at hand, and in those cases 
metaclasses and multihierarchies are sometimes 
used to overcome the lack of primitives (Ian's 
examples suffice).

>Having said all that, I am not asserting that no convincing use case
>exists. The classic example from WebOnt was Guus's
>Species-Elephant-Jumbo. In these cases, however, the Meta-Class
>generally seems to be serving a mainly organisational or documentary
>function (I think that someone already made a similar point in this
>thread), and has very little impact on the semantics of the classes
>and instances in the ontology. In fact I don't know of *any* example
>where the Meta-Classes use constraints to specify logical
>characteristics that are inherited by the classes that that
>instantiate them. It therefore seems to make sense to use a *very*
>much simpler language to describe meta-classes, one that would have
>little if any impact on the problem of reasoning about classes and
>individuals, or perhaps even to treat meta-classes as a form of
>documentation.
>
>Ian

I agree also on this. So-called "taxa" in Linnean 
taxonomies serve an organizational function, 
although they also have proper constraints (a 
species cannot be a species unless it has a 
superclass that is a genus, etc.).
But once we try to analyze those constraints, 
they can be found to be approximations. In fact, 
modern classification of organisms has many 
classes that fall in between Linnean metaclasses, 
originating the need for e.g. subfamily, 
superfamily, suborder, etc. (for a sample resume 
of the criteria used in different 
classifications: 
http://www.science.siu.edu/plant-biology/PLB449/DLN.449lectures/Phylocode.htm).

Another motivation for metaclasses has been 
advocated for properties that hold of a class in 
general, but not necessarily of any instance of 
that class. For example, "nursing newborns" is a 
property of mammals, but not of each instance of 
mammals (e.g. of males or young females). In my 
opinion, this is also a shortcut for something 
that in principle requires a more detailed 
analysis, leading in this case to a more complex 
restriction, stating that "for all newborns of 
mammals, there is a need to be nursed with a 
proper substance, and a subclass of this proper 
substance is secreted by certain glands found in 
grown females that have just delivered".

Then, such organizational notions could well be 
implemented as annotations, like documentation, 
comments, encodings, etc., or may require a 
complex modelling such as the one I have 
mentioned (but staying at the object level).

At this point one could wonder if there are real 
logical metaclasses, which need reasoning 
facilities.
There are some cases that obviously require them, 
and they concern modelling primitives, for 
example the OWL namespace, the RDFS namespace, 
the built-in theories of most knowledge 
represenation systems, etc. In these cases, it's 
the structure of the language that is exploited 
by the reasoner to draw inferences, then one may 
be intersted in modifying that structure, at the 
cost of losing compatibility with other users, or 
of losing some functionalities tout court. But I 
think that these metaclasses have been discussed 
enough e.g. in the WebOnt WG, and are only 
indirectly of interest here.

In some cases, we need to produce new schemas 
including metaclasses, e.g. in order to produce a 
schema for WordNet (see related thread in this 
WG), but the resulting ontology will not be used 
to reason in the same problem space as the 
ontologies depending on that schema.

Another set of metaclasses that maybe requires 
reasoning in the same problem space as the 
classes that are instances of them are the 
metaclasses defined in e.g. the OntoClean papers 
by Nicola and Chris ("role", "type", "non-rigid", 
etc.). These have been implemented in various 
systems (Protégé, OntoEdit, WebOde, Web-KB) just 
as annotations, following the suggestion given 
above.
On the other hand, those metaclasses have 
originally rich axiomatizations involving classes 
and relations at the object level. E.g., a "type" 
class implies that all its instances have that 
property for all their lifecycle, thus it could 
be interesting to check if there is any 
individual of a "type" class that is not 
preserving that property across time.

But even in the last case, it is possible to 
reduce the problem to a matter of relations 
between individuals and roles that they play, 
putting both individuals and (reified) roles in 
the same domain. See for this solution our recent 
paper to appear in the next KR04. A report 
derived from it will be available at the LOA site 
(http://www.loa-cnr.it) in the next weeks.

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.
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.

Aldo

PS oops, my two cents have become twenty cents ...
-- 



*;*;*;*;*;*;*;*;*;*;*;*;*;*;*;*;*;*;*;*;*;*
Aldo Gangemi
Research Scientist
Laboratory for Applied Ontology, ISTC-CNR
Institute of Cognitive Sciences and Technologies
(Laboratorio di Ontologia Applicata,
Istituto di Scienze e Tecnologie della Cognizione,
Consiglio Nazionale delle Ricerche)
Viale Marx 15, 00137
Roma Italy
+3906.86090249
+3906.824737 (fax)
mailto://a.gangemi@istc.cnr.it
mailto://gangemi@acm.org
http://www.loa-cnr.it