Re: Importing SKOS model in ontology editors : clash with annotation properties

Hi Bernard,

Simon Jupp wrote in another thread:
 > The current behaviour  is down to P4
 > guessing what you might have meant in your file.

We sometimes even encourage some of our customers to use OWL full (!). 
The reason is that an ontology is a conceptualization which should be 
easily comprehensable by humans. And if using OWL full provides a 
natural model this is perfectly fine -- for humans.

BUT if a customer uses OWL full we urgently encourage him (i.e. we 
support him) in providing also an OWL DL (in our company eben an OWL 
DLP, OWL2 EL or OWL2 RL) version of his conceptualization. We call this 
a "prune", because from a formal point of view this light version is 
much less expressive compared to the original version.

Deriving such a prune is exactly the way how to reduce complexity in 
order to make things fly. To our experience always ever it can be shown 
that such a prune reflects the intended semantics and pragmatics of a 
conceptualization of the customer much more than the original complex 
version.

However, in the end it is the customer (here: the SKOS editors) who have 
to agree on which prune is minimally acceptable.


Here you point to such a prune candidate:
 > http://www.w3.org/2006/07/SWD/SKOS/reference/20081001/skos-dl.rdf

I have fed this to
- http://www.mygrid.org.uk/OWL/Validator
which gives back OWL DL plus some minor errors ("Possibly using wrong 
vocabulary (rdf:Property instead of owl:[Object|Data]Property)...")

additionally it reports
     * Disjoint Classes axiom found:
       DisjointClasses(a:Collection a:ConceptScheme)
     * Disjoint Classes axiom found:
       DisjointClasses(a:Concept a:ConceptScheme)
     * Disjoint Classes axiom found:
       DisjointClasses(a:Collection a:Concept)
     * Or: unionOf(a:Collection a:Concept)

Then we have a first question:
- Would the editors of SKOS agree that this (or a similar) OWL DL subset 
   reflects most of their *intended* semantic?

Additionally I have another question:

(either) Do we really have to interpret the four disjoint statements as 
they are? This would allow for sophisticated classification and type 
entailment (but *not* schema check). Then we really have OWL DL, which 
is known to be sound and complete but not tractable in large scale

(or) or would it make sense to interpret the disjoint statements as 
"integrity constraints", (throwing away some type entailment abilities 
but) allowing for schema check and much faster inferencing instead? Then 
we can work with a skos ontology in two modes:
- mode 1, schema check: give all concepts which are used in a strange 
way -> and ask the terminology staff to provide simpler solutions
- mode 2, fast inferencing: assumed that the KOS schema check is ok: 
what can we derive then even with large terminologies?

Note that fast inferencing (i.e mode 2) is only possible whith a 
complexity like OWL DLP (but not OWL DL), OWL2 EL, OWL2 RL etc.


yours
Johannes



  Vatant wrote:
> Hi Johannes
> 
> Your viewpoint is indeed very interesting.  Maybe the "semantic 
> skeleton" you are asking for is defined at
> http://www.w3.org/2006/07/SWD/SKOS/reference/20081001/skos-dl.rdf
> I discovered it while browsing this list archive, but surprisingly 
> enough, even the SKOS editors themeselves do not seem to be quite clear 
> about the satus of this model, which is, as the URI suggests, OWL-DL.
> See e.g., Antoine Isaac answer to Thomas Baker about it at
> http://lists.w3.org/Archives/Public/public-swd-wg/2009Mar/0054.html
> 
> As an aside, I had a similar issue with the Geonames ontology. In the 
> first version of it, I wanted to stick to OWL-DL and even OWL-Lite, but  
> some people including Tim Berners-Lee himself insisted that the labeling 
> attributes such as geonames:name, geonames:alternateName and 
> geonames:officialName should be subproperties of rdfs:label, in order 
> for RDF tools such as Tabulator to use them for display purposes. The 
> solution adopted (I can't remember the original author of this proposal 
> now, unfortunately) was to have an OWL-Lite version without this 
> subproperties assertions, and an OWL-Full version importing the OWL-Lite 
> version and just adding the subproperties assertions.
> See http://www.geonames.org/ontology/ontology_v2.0_Full.rdf
> 
> Seems to me that could be done for SKOS model in asimilar way, making 
> everybody happy. The subproperties assertions have to be there for 
> search engines such as Sindice, RDF browsers such as Tabulator, while 
> reasoners could get rid of them and stick to the DL model, being more 
> interested in semantic relationships between concepts.
> 
> Bernard
> 
>> Dear SKOS editors,
>>
>>
>> (my personal view:)
>>
>> I'm working at a little company, which provides a nice and fast 
>> ontology language (called F-logic, which is sort of a enhanced 
>> datalog). We also have an own OWL reasoner implementation (which does 
>> OWL DL A-Box inferencing pretty fast). And of course we have an 
>> ontolog engineering environment (called OntoStudio) which allows for 
>> an (as far this is possible) integrated view on F-logic and OWL.
>>
>> The industrial customers of our semantic technologies want to be sure 
>> that we provide inferencing which is sound and complete. They 
>> explicitely require that we do not apply "semantic heuristics" which 
>> are not well defined. This means that from a contractual point of view 
>> we are not allowed to prune a 3rd party OWL full ontology into an OWL 
>> DL (or OWL2 EL, OWL2 R etc) ontology.
>>
>> After long discussions we have decided *not* to support even *loading* 
>> OWL full ontologies into our systems. Why? While we of course often 
>> can *guess* which parts of an OWL full ontology are there mainly in 
>> order to communicate the understanding of an ontology (as opposed to 
>> do inferencing with it) we do not *know* that for sure. I.e. we cannot 
>> prove that a specific semantic model for our customer is at least 
>> correct when there was an OWL full ontology in the chain.
>>
>> As a result we cannot use the skos2008 version as it is. As long as 
>> there is only an OWL full version of SKOS this standard remains 
>> academic. We simply stick to skos2004 until things get better.
>>
>> I understand that things will become much better when OWL2 is 
>> finished. (But please give us some time and resources to implement 
>> OWL2 then; it's pretty complex).
>>
>> For the time being I'd like to ask whether it is possible for you to 
>> provide a "semantic skeleton" of skos2008, which has to be sound and 
>> complete, but neverttheless equivalent to your intended semantics of 
>> skos 2008.
>>
>> This is something which has to be done by the authors themself, 
>> because we are speaking here of standards and intentions. This also 
>> would help to communicate the very core of the skos idea in a simple way.
>>
>>
>> yours
>> Johannes
>>
>>
>> PS: Using skos 2008 (i.e. integrating it with other ontolgies) 
>> additionally would be even more interesting if the semantic skeleton 
>> of skos2008 would prove to be OWL1 ultralite, OWL2 EL, OWL2 RL or any 
>> other *fast and simple* OWL2 profile. (Even OWL DL ist to complex to 
>> allow for large scale inferencing.) Then skos would in faxt remain a 
>> simple KOS, which could in fact act as a very nice, lightweight and 
>> powerful (1) stand alone starting point and (2) extension to many 
>> other ontology projects.
>>
>>
>>
>> Bernard Vatant wrote:
>>> Hello
>>>
>>> I'm not sure SKOS editors were aware of the behavior of various OWL 
>>> ontology editors regarding the handling of the annotation properties 
>>> (labels and documentation) in the current SKOS model.
>>> To declare rdfs:subPropertyOf relationships between annotation 
>>> properties is definitely a OWL-Full feature at least in OWL 1.0. I 
>>> can read in the reference document that this feature "makes SKOS more 
>>> usable with the OWL 2 specification currently in development". Not 
>>> sure about what will come out of OWL 2.0, but when using OWL 1.0 
>>> ontology editors, this situation leads to various inconsistent 
>>> behaviours. Basically they do not support this kind of construction, 
>>> and they get rid of it in different ways.
>>>
>>> Examples:
>>>
>>> SWOOP 2.3 latest (and last) release - I know this one is a bit old 
>>> and no more under development, but I keep using it default of better 
>>> free lightweight tool.
>>> The rdfs:subProperty relationships between annotation properties are 
>>> simply ignored, and if you save the model, they are definitely off.
>>>
>>> Protégé 4.0 decides that "pure" annotation properties can't be the 
>>> subject of assertions, so it considers all the annotation properties 
>>> participating in the subproperty statements are object properties 
>>> (but still annotation properties), which seems weird to me. There 
>>> again, if the model is saved, properties are saved this way.
>>>
>>> Remarkably enough, none of those tools signal any error or trigger 
>>> any warning when loading the file. Which is unfortunate indeed.
>>> It's been a daily routine in Mondeca to merge the SKOS model into 
>>> wider customer ontologies we manage with the above editors.
>>> And I guess we are not alone in this case.
>>>
>>> I have no solid proposal to deal with that issue, but just wondering 
>>> if others have stumbled on it.
>>>
>>> Cheers
>>>
>>> Bernard
>>>
>>
>>
> 
> 


-- 
Dr. Johannes Busse, Senior Researcher
An der RaumFabrik 29, D-76227 Karlsruhe
Reg. Office: Karlsruhe, Amtsger. Mannheim, HRB 109540
Managing Directors:    Prof.Dr.J.Angele,  H.P.Schnurr
http://www.ontoprise.de   | phone x49(721) 509 809-62
mailto:busse@ontoprise.de | mobile x49(163) 509 80-62

Received on Wednesday, 25 March 2009 10:18:07 UTC