Unique Name Assumption

[Ed Shaya]

Elyses,
	Yes, there still remains a bit of a problem even with Classes, but how 
serious is this problem?  Let's examine the non-unique name assumption 
problem for individuals and classes separately;

	With individuals there is the problem that <Carbon 
rdf:ID="MyCarbonAtom"> is not distinct from <Carbon 
rdf:ID="MyOtherCarbonAtom"> until you say it is Distinct.  Nor is it 
assumed to be the same.  So if you give different Locations for the two 
(and Location is a Functional property) then a reasoner will know that 
these are different and if you try to say they are the same, then you 
will hit an error.  Until you have contradictory properties, they could 
be the same and you can state they are the same.  I think this way of 
doing things works out just right for us astronomer folks.  We have lots 
of names for any given object and so when we find two individuals of the 
same class with different names we do not know a priori if they are the 
same or not, we always need to run some sort of test on the properties 
to find this out.

	With Classes there could be confusion if the Class properties are not 
well spelled out.  Consider MyCarbonAtom and MySiliconAtom.  If the 
ontology just says Carbon and Silicon are subClassOf Element, then these 
two could be the same thing.  However, if Carbon is defined with 
arestriction on atomic number hasValue 6 and Silicon hasValue 14, then 
reasoners automatically (should) know that Carbon and Silicon are 
disjoint, therefore a Carbon individual cannot be the sameAs a Silicon 
Individual.

	Still there will be times when Class properties are not sufficiently 
distinct from one another for a reasoner to assume disjointedness and 
one should use disjointWith there as you say.  Perhaps there is a speed 
advantage to stating it explicitly for all pairs of Classes.  I just 
know that when I did that, the ontology became
unreadable.  Maybe I am not suppose to be able to read it.

Cheers,
Ed

Elyes Lehtihet wrote:
> Even by using Classes you will still have to deal with the unique name 
> assumption. Again the only solution is to add systematically 
> 'owl:AllDisjoint' axioms between sibling classes - that should work if 
> you are not using too much multiple inheritance... the reasoner will 
> eventually infer inconsistencies...
> 
> All the best,
> Elyes
> 
> ------------- On 18/04/2007 22:40,Ed Shaya wrote:
>> It does not seem to me to be a good idea to make individual 
>> elements/atoms instances in the first place.  What if someone needs to 
>> refer to a specific atom sitting in their Atomic Force Microscope 
>> (AFM)?  For this you would want to make an individual of the Class 
>> Carbon.
>> <Carbon rdf:ID="MyCarbonAtom"/> where Carbon is a class.  This also 
>> makes it possible to add isotopic species as subclasses.  We should 
>> refrain from using individuals except for a named individual in the 
>> universe: Earth, Algol, M31, Mike Brown, MyBigRedChair.
>>
>> One still should make the various types of atoms owl:disjointWith, 
>> but, as I mentioned previously, we really need a new version of OWL to 
>> make this more manageable because nearly every class is distinct from 
>> every other class in astronomy.  In any event the only loss if you do 
>> not use disjointWith is that a reasoner can not spot an error if 
>> someone tries MyCarbonAtom is both Carbon and Silicon.
>>
>> Ed
>>
>>
>> Thanks, Elyes for pointing out a weakness here.
>> Ed
>>
>>
>> Elyes Lehtihet wrote:
>>> Hello,
>>>
>>> While exploring the AstroOntology, I have noticed that you create a 
>>> set of individuals (instances) of the AtomicElement, SpectralType, 
>>> etc. As you probably know, the web ontology language use the Unique 
>>> Name Assumption: every concept is not, by default, necessary distinct 
>>> from the others. It implies that the instances of your classes are 
>>> not made 'explicitly' distinct for the reasoners : Carbon is not 
>>> explicitly distinct from Calcium, etc. etc.
>>>
>>> The common pattern to solve this problem is to create an 
>>> 'owl:AllDifferents' axiom (Protégé: OWL/Edit owl:AllDifferents...) 
>>> that regroups the set of instances. After, one should create a new 
>>> expression to enumerate the allowed values of the class. Example for 
>>> the LuminosityClass: {LuminosityClassII LuminosityClassV 
>>> LuminosityClassIII LuminosityClassIV LuminosityClassI}
>>> This method assumes that a Class cannot take other values than the 
>>> ones explicitly defined by the enumeration - But maybe there are more 
>>> AtomicElement than the 14 that are cited :-)
>>>
>>> Best regards,
>>> Elyes
>>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eshaya.vcf
Type: text/x-vcard
Size: 257 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/semantics/attachments/20070419/fff4becf/attachment-0001.vcf>