[OWL] using equivalentClass in an anonymous class - 1.1 bnode rule modification?

[Peter F. Patel-Schneider]

From: Alan Ruttenberg <alanruttenberg at gmail.com>
Subject: Re: [OWL] using equivalentClass in an anonymous class - 1.1 bnode rule modification?
Date: Fri, 23 Dec 2005 22:42:17 -0500

> Here's what I was trying to do. In order to deal with the issue of  
> having multiple individuals which really meant the same thing (see my  
> post "Desire for more flexible way to determine same individual") I  
> reasoned as follows.
> 
> I have the following problem - in my earlier post I gave as an  
> example the desire that all instances representing the database entry  
> 7157 from  entrez gene be considered the same individual. Suppose I  
> want  some combination of properties to effectively uniquely  
> determine an individual. I reasoned as follows:
> 
> - Any inferred individuals of a nominal with a single member are  
> sameAs that member. Call our chosen nominal class N. In order to  
> define this class, I need to have some individual to define it with.  
> Be noncommittal - create an individual  member of Thing and call it M.
> - I can use a combination of equivalentClass and restrictions  
> (protege language "necessary and sufficient" conditions) to have  
> individuals be automatically be considered members of a class. Call  
> the class I create F
> - Make F  a subclass of N.

> - Any individual R with the desired properties is a member of F.

> - Because F is a subclass of N R is also a member of N.

> - Because R is a member of N, R is sameAs M (as well as are all the  
> other individuals with these properties)

All of the above can be easily done, via

	SubClassOf(intersectionOf(
		restriction(db(hasValue("entrez"^^xsd:string)))
		restriction(id(hasValue("7157"^^xsd:string)))
	  oneOf(magnetInstance4)
	)

To give magnetInstance4 the "right" properties also say

	Individual(magnetInstance4
		value(db "entrez"^^xsd:string)
		value(id "7157"^^xsd:string))

There is no need to have anonymous class structures participate in multiple
syntactic constructs.

The meaning in OWL DL of an anonymous class structure (a.k.a., description) is
entirely determined by its syntax.  There is this no harm in duplicating it.


The above can actually be done more simply, as 

	Individual(magnetInstance4)
	EquivalentClasses(intersectionOf(
		restriction(db(hasValue("entrez"^^xsd:string)))
		restriction(id(hasValue("7157"^^xsd:string)))
	  oneOf(magnetInstance4)
	)

> To experiment with this I tried to use Matthew Horridge's OWL DL  
> Individuals tab. However, although i was able to make an individual a  
> member of an anonymous class, it didn't let me do the equivalent  
> class part. I edited the XML to do what I thought was the right  
> thing. If, in the code I cite,  <rdf:type> <owl:Class> , is changed  
> to <rdf:type> <owl:Class rdf:ID="nameMe">, then Pellet says it is OWL  
> DL.

> In the example below, M is magnetInstance4, N is the <oneOf...>, F is  
> the <intersectionOf...>.
> 
> Now, from my previous discussion with Sean and Uli, I might agree  
> that this is wierd.  Maybe it will cause reasoners to perform badly.  
> Maybe the version with <rdf:type> <owl:Class rdf:ID="nameMe"> is also  
> wrong, and Pellet has a bug. That's OK. If true, let me know.
> 
> Assuming Pellet was correct, I found it counterintuitive that it was  
> a property of the language that removing a single rdf:ID would change  
> a correct document to an incorrect document.  Both you and Sean  
> suggested that a shared structure violation could be remedied by  
> copying the structure in question, which led to my last question.
> 
> Maybe this is an issue with the embedding of OWL in RDF which you  
> refer to - I'm not familiar with the historic arguments for or  
> against (I'm guessing that it was one of those marketing things). I  
> just figure that it would useful to be able to understand the  
> specification as it is. There are two points of interest for me. The  
> first is in getting an acceptable solution to the problem. The second  
> is understanding the finer points of the specification.

Well, in general messing with OWL encoded in RDF/XML is a difficult endeavour -
to be avoided like the plague.

> -Alan


peter