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

Hi all,

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. 

This position also fits with all of the information retrieval use cases for SKOS. I.e. if you want to use SKOS for "conceptual" search, navigation and browsing, you don't need a formal semantics at all.

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.

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 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.

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.

Cheers,

Alistair.
 



 






> -----Original Message-----
> From: Antoine Isaac [mailto:aisaac@few.vu.nl] 
> Sent: 30 October 2007 17:14
> To: dlrubin@stanford.edu
> Cc: Miles, AJ (Alistair); SWD WG
> Subject: Re: [SKOS] Resolutions on concept semantics
> 
> OK, going back to the subject, the minutes of today's telecon 
> will say:
> > We make no statement either way about whether skos:Concept 
> is disjoint 
> > or not disjoint with owl:Class
> 
> I can live with this formulation, which is actually different 
> from the one in the F2F minutes which was "we will not say 
> anything about the disjointness. we should make clear that 
> the omission is explicit"
> 
> But I would like to have things put clearly here. *If there 
> is something about this issue in one of the SKOS document, 
> then it cannot be something like "skos:Concept may be 
> disjoint with owl:Class or not."* We must be coherent he: if 
> for us there is a possibility for someone somewhere somewhen 
> to create something that is both a skos:Concept and an 
> owl:Class, then we cannot honnestly say that "owl:Class and 
> skos:Concept may be disjoint".
> 
> And I cannot imagine something like a "local interpretation 
> of SKOS" for which skos:Concept and owl:Class are disjoint. 
> This would be overcommitting to what was defined in the SKOS 
> *standard* and, since the two alternatives are contradictory, 
> could raise serious interoperability issues, as Daniel mentioned.
> 
> Cheers,
> 
> Antoine
> 
> 
> 
> >
> > It seems there are several interpretations of "saying 
> nothing" here...
> > To me saying nothing on the disjointness amounts to say 
> that there are 
> > not disjoint. The idea is that people can do what they want 
> with their 
> > concepts, including declaring some as classes or keeping them 
> > distinct. If we have to find a common denominator for these 
> different 
> > situations, then it is "non-disjointess".
> >
> > As Daniel I also don't like the idea of letting people 
> decide whether 
> > skos:concept is disjoint or not. SKOS is defined by us, and 
> we cannot 
> > have people making different interpretations of the shared SKOS 
> > construct, especially when they can be conflicting.
> > What users can do of course is to say that *their* SKOS 
> concepts are 
> > disjoint from owl:Class (e.g. by creating a subclass of 
> skos:Concept 
> > that is disjoint with owl:Class). But this is another story...
> >
> > Cheers,
> >
> > Antoine
> >>
> >> I am opposed to *saying nothing* about disjointness between 
> >> skos:Concept and owl:Class (actually, in general I'm opposed to 
> >> leaving any semantics undefined in SKOS)--if you leave any 
> semantics 
> >> up to the user to decide, then you ensure people will have 
> different 
> >> meanings for the same entities and relations, making 
> interoperability 
> >> impossible.
> >> Daniel
> >>
> >> Quoting "Miles, AJ (Alistair)" <A.J.Miles@rl.ac.uk>:
> >>
> >>>
> >>> Hi Antoine,
> >>>
> >>>> >
> >>>> > [following discussion on the OWL/SKOS patterns] ... we are not 
> >>>> > discussing the introduction of new properties, but the 
> semantics 
> >>>> > of skos:Concept, in particular its disjointness with owl:Class
> >>>> > aliman: we will not say anything about the disjointness
> >>>> > sean: we should make clear that the omission is explicit
> >>>>
> >>>>  3. RESOLUTION: skos:Concept is not disjoint with owl:Class .
> >>>> Some instances of SKOS concept may be also declared (and
> >>>> treated) as OWL classes, and vice versa.
> >>>
> >>> I thought our resolution was to *say nothing* about disjointness 
> >>> between skos:Concept and owl:Class. That would give people the 
> >>> freedom to interpret them as disjoint, if they want to do 
> that, or 
> >>> not, if they don't.
> >>>
> >>> That's what I tried to capture in:
> >>>
> >>> [1]
> >>> 
> <http://www.w3.org/2006/07/SWD/wiki/SKOS/Reference/Concepts?action=r
> >>> ecall&rev=10>
> >>>
> >>>
> >>>> From [1] ...
> >>>
> >>> "The decision to leave the formal semantics of skos:Concept 
> >>> undefined has been made to allow different design 
> patterns for using  
> >>> SKOS in combination with more formal languages such as OWL to be 
> >>> explored.
> >>>
> >>> For example, interpreting skos:Concept and owl:Class as disjoint 
> >>> classes would be consistent with the semantics of SKOS.
> >>> Alternatively, interpreting skos:Concept as a super-class of 
> >>> owl:Class would also be consistent with the semantics of SKOS."
> >>>
> >>> Cheers,
> >>>
> >>> Al.
> >>>
> >>>
> >>
> >>
> >>
> >>
> >
> >
> >
> 
> 


--
Alistair Miles
Research Associate
Science and Technology Facilities Council
Rutherford Appleton Laboratory
Harwell Science and Innovation Campus
Didcot
Oxfordshire OX11 0QX
United Kingdom
Web: http://purl.org/net/aliman
Email: a.j.miles@rl.ac.uk
Tel: +44 (0)1235 445440

Received on Tuesday, 6 November 2007 15:58:30 UTC