Re: [SKOS] Resolutions on concept semantics (ISSUE-54)

Hi Alistair,

> At the face-to-face in Amsterdam, we seemed to be moving towards a consensus position that SKOS is, by design, a semi-formal language. It is "semi-formal" because it has a formal syntax -- the RDF abstract syntax -- but its semantics are, for the most part, defined informally.
>
> This position fits well with the thesaurus, classification scheme and subject heading traditions, where there are informal notions of navigational structures -- hierarchical and associative relationships -- but there are no formal (model-theoretic) semantics whatsoever.  
>
> This position also gives SKOS its unique selling point, and clearly differentiates it from OWL. OWL is a formal language with a formal, model-theoretic semantics; SKOS is a semi-formal language, with a mostly informal semantics. OWL is a heavy-weight language with many logical consequences; SKOS is a lightweight language with very few logical consequences. OWL is suited to detailed modeling and reasoning; SKOS is suited to modeling intuitive conceptual structures, used for retrieval, navigation and browsing. 
>
>   
I think I disagree on this. Or I fundamentally agree, but the wording is 
I think dangerous.
Since SKOS is defined as a vocabulary for RDF, which have formal 
semantics, then I think it is by essence a formal language. The point is 
that its formal axioms are limited, since the KOS domain has not defined 
clear and extensive semantics. In other words: it's a lighweight 
semantic web ontology, ok, but it is a semantic web ontology.

> How does this position relate to the question of the formal semantics of skos:Concept, and especially its relationship to owl:Class?
>
> Well, if we take this position, then we should make our formal commitment as small as possible, adopting the bare minimum required to satisfy the majority of our use cases. In other words, we say only what we need to say to define the language, and nothing more. In this case, we say skos:Concept rdf:type owl:Class, and that is all.
>   

I think I slightly disagree on the approach. For me we want to capture 
as much formal semantics as we can. But there are indeed candidate 
formal axioms that would make SKOS incompatible with some use cases, so 
we don't commit to them.

> There are other reasons for not taking a position on the formal semantics of skos:Concept. In [1] I tried to capture what I see as the major design patterns for working with SKOS and OWL.
>
> [1] <http://isegserv.itd.rl.ac.uk/public/skos/2007/10/f2f/skos-owl-patterns.html>
>
> Note first that this is speculative, and based on discussions with various researchers working in the area over the last couple of years. I.e. this is still research work.
>
> Second, I would be very uncomfortable ruling out any of these design patterns. But if we take a position on whether or not skos:Concept is disjoint with owl:Class, that is exactly what we would do. 

I think there is a misunderstanding. As far as I'm concerned, I do want 
to say that skos:Concept is not disjoint with owl:Class because that's 
indeed the only solution that is compatible with all your patterns 
there. The only commitment that is in this axiom is "beware, you mind 
find somewhere skos:Concepts that are also owl:Classes". I really don't 
see where is the problem.
What I also do want to avoid is people putting in their repository the 
axiom "skos:Concept disjointWith owl:Class", or even to think that all 
the SKOS application they could encounter would make this hidden 
assumption. Because this would ruin interoperability, as Daniel as said.

> I think all of these patterns are important, and are very likely to be used under a variety of different circumstances. I think these patterns needs to be explored, and that will take time.
>
> Third, if we were to rule out one or more of these design patterns, we would effectively be mandating one particular way of using SKOS and OWL in combination. But this is arguably out of scope for our working group. I.e. it's our job to define the SKOS language, and we can suggest possible ways of using SKOS and OWL together, but it's not our job to say how you must or must not use SKOS and OWL together.
>
> Finally, I note the concern that, if we take this position, then different communities of practice may emerge where SKOS and OWL are used together in different ways, and that these communities may not be compatible with each other. However, note that the incompatibility arises out of the interaction between SKOS and OWL -- considering SKOS only, there would be no incompatibility. Therefore the majority of our use cases would not be affected. But more importantly, I just don't think we're in a position to mandate one option or another. I've heard many people expressing a preference for both patterns, and I want to give them all a chance to explore the different possible interactions between SKOS and OWL. And finally, note that there are already effectively two separate communities of practice in the OWL world -- those who stay within DL, and those who don't. I don't think it's our problem to fix.
>   
So in the end your first statement would prove true: different 
communities of practise mixing OWL and SKOS in different ways, perhaps 
missing each other's information. But I also agree with you: we cannot 
rule out any of the patterns. Our only concern (at least for the moment) 
should be that they are not formally incompatible.
> Sorry this hasn't been the most concise discussion, but I'm still working a lot of this through in my head. I look forward to your thoughts.
>   

I hope this brings not-too-stupid discussion.
In turn, I'd like your opinion on the "not-disjoint axiom". You seem to 
consider there is a problem with it since some mails already, and I'd 
like to understand why.

Cheers,

Antoine

Received on Tuesday, 6 November 2007 18:41:47 UTC