Unique Name Assumption

[Elyes Lehtihet]

Ed,
I am not an expert in Astronomy but I have some experience on creating 
ontologies for network management. I came to the conclusion that there 
isn't *one* correct way of developing an Ontology - It depends on the 
domain and most importantly on the domains experts. However, there are 
some common design patterns that should be considered when trying to 
capture a domain knowledge.
Reasoners do not take into account datatypes, so your example for 
'hasValue = 6 or 14' will not be considered. this limitation should be 
solved with the next version of DIG reasoners and the adoption of OWL1.1 
(I suppose!). Then, as I mentioned before, the pattern that consist in 
'systematically' adding disjunctions between sibling classes is not 
applicable if you use multiple inheritance in your ontology OR if it is 
not appropriate regarding your domain.
The short answer is: I am not an expert in Astronomy so I don't know the 
'exact' purposes of you ontology and what degree of complexity you 
require...

All the best,
Elyes


------------- On 19/04/2007 17:51,Ed Shaya wrote:
> 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
>>>>