Re: [SKOS] inScheme and rdfs:isDefinedBy (cf. ISSUE-36 ConceptSchemeContainment)

Hi Alistair et al,

=============
INTRO (verbose -- feel free to skip to the PROPOSAL section below)
=============

When we designed the Registry, we also asked Bernard's second
question: "How can one find out all the concepts in a concept scheme
in an open world, if there is no explicit declaration of some inverse
property of skos:inScheme?" and we've struggled with tension between
the notion of a skos:Concept as an independent Individual floating in
the open universe of the Semantic Web, free from ConceptScheme
bindings and thus hard to find, and the notion of a skos:Concept as an
Individual that can only be discovered, and effectively managed, in
the context of a single CS.

We also had to figure out how to share Concepts and how to manage
relationships between Concepts when they were 'in' CSs managed by
different Agents. This is where the lack of some formal ability in
skos to declare a list of the Concepts 'contained' by, or a CS became
a problem. The assertion of skos:inScheme, being a skos:Concept
property, is explicitly 'owned' by the agent who is the 'owner' of the
Concept. This makes it problematic for another agent to include a
Concept for which they are not the owner in their CS by simply adding
a skos:inScheme property to the Concept.

skos semantic relations present a similar "who owns the property"
problem, along with the additional problem raised in Issue-36 and
Sean's initial email "How might I represent the fact that the semantic
relationships between concepts occur within a particular scheme?" As
you point out in your discussion piece, for a vocabulary manager
simply 'including' a foreign CS (foreign meaning 'in another
namespace') in your CS produces the often undesirable effect of adding
a bunch of Concepts to your CS that you don't want, it doesn't solve
any of the property ownership problems, and it doesn't resolve the
issue.

So in the context of the Metadata Registry's use of skos in vocabulary
management, we do several things by convention that might more
usefully defined at the skos vocabulary level. For one thing we
enforce a one-to-one relationship between a skos:ConceptScheme and an
xml namespace. This allows us to serve a namespace document that lists
the skos:Concepts 'contained' by that CS/namespace. It's effective,
but we don't think this is necessarily the best way to express or
locate the set of Concepts related to a CS. And it doesn't scale well.
We also currently allow the creation of semantic relations between
Concepts in different CSs without the explicit endorsement of the
inverse or reciprocal properties by the owner of the target Concept.
This is not a good thing.

We've also lately started thinking about how we will use skos:Concepts
and CSs in the context of Dublin Core Application Profiles. We have
some funding to register DCAPs which we will try to express as an
owl:Ontology. This has gotten us thinking at the ontology level rather
than just at the CS level.

=========
PROPOSAL
=========

I'd like to propose that it might be useful to approach this problem
from the ontology level...

If we were to declare a skos:ConceptScheme to be something other than
a subclass of owl:ontology (which I think you proposed largely to
support the owl:imports property) but instead require that a CS have
an rdfs:isDefinedBy property (or something similar that might be a
FunctionalProperty in skos) that would effectively bind the CS to a
single owl:Ontology. A skos:Concept would also be required to have
either a skos:inScheme property that binds it to a CS or an
rdfs:isDefinedBy property that binds it to a single owl:ontology.
Allowing either type of binding would allow skos:Concepts to be
contextualized by explicit definition in the context of an ontology
without necessarily requiring membership in a CS.

We would also declare that semantic relations between skos:Concepts
are only valid in the semi-closed world of an owl:ontology (including
imports). Only by importing an ontology could the vocabulary manager
'use' the Concepts and CSs DefinedBy that ontology. A vocabulary
manager wishing to include Concepts from a foreign CS in a local CS,
or create semantic relationships between Concepts in a foreign CS,
would import the entire ontology which defines it.

This would also have the desirable effect of clearly maintaining
provenance of the imported CSs and Concepts, as well as localize the
provenance of relationship properties. The imported Concepts would
remain effectively immutable wrt to the importing ontology, preserving
ownership of their definition. The declaration of semantic
relationship properties would be constrained to the locally-owned
Concepts and reciprocal properties would be 'added' to imported
Concepts by inference. Existing semantic relations in the imported
ontology(s) would be maintained and their 'local' validity would be
extended to the importing ontology. If a vocabulary manager wished to
actually make changes to imported Concepts and CSs, these changes
would only be considered to be valid in the context of the local
ontology.

By declaring that skos:Concepts must be either a member of a
skos:ConceptScheme or DefinedBy an ontology, and skos:ConceptSchemes
must be DefinedBy an ontology, we would essentially provide a way to
support the notions of "Every concept has a home" and "Schemes can
import other schemes" (both of which I endorse). And by decoupling the
semantics of skos:ConceptScheme from the semantics of owl:ontology we
can be more specific about what we consider a skos:ConceptScheme to
be.

Personally I think it would be useful to define a CS as a finite,
closed list of skos:Concepts. Perhaps by simply adding a
skos:hasConcept property to complement the existing
skos:hasTopConcept, and declaring it to be an inverse property of
skos:inScheme? It might also be useful for a CS to have a
skos:importsScheme property to make it quick and easy to assemble a CS
from components.

Cheers,
Jon

On Nov 6, 2007 9:58 AM, Miles, AJ (Alistair) <A.J.Miles@rl.ac.uk> wrote:
>
> Hi all,
>
> I agree with Antoine to re-open ISSUE-36.
>
> I also agree that there may be important differences between the semantics of rdfs:isDefinedBy and skos:inScheme, such that one cannot be a sub-property of the other.
>
> I suggest we divide the problem into two:
>
> First, we decide what we want to express.
>
> Then, we look at existing vocabulary, in particular rdfs:isDefinedBy and skos:inScheme, and see if we can use it. If not, we invent new vocabulary.
>
> When discussing the first point, we must bear in mind that, as Guus has pointed out, OWL has no vocabulary for explicitly stating a relationship between a class, property or individual and the ontology in which it is defined. Yet, OWL applications have worked fine so far without need for any such vocabulary. Therefore, we must carefully consider which use cases establish a firm requirement for such vocabulary in SKOS, and why there are no analogous use cases for OWL. I.e. why is SKOS special?
>
> To stimulate discussion of the first point only, I've written some ideas down at:
>
> [1] <http://www.w3.org/2006/07/SWD/wiki/SkosDesign/ConceptSchemes/DiscussionPiece>
>
> Note that this is not a proposal, just a discussion piece, illustrating one possible point of view and some of its consequences.
>
> Cheers,
>
> Alistair.
>
>
>
> --
> 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
>
>
> > -----Original Message-----
> > From: public-swd-wg-request@w3.org
> > [mailto:public-swd-wg-request@w3.org] On Behalf Of Antoine Isaac
> > Sent: 30 October 2007 17:00
> > To: SWD WG
> > Subject: [SKOS] inScheme and rdfs:isDefinedBy (cf. ISSUE-36
> > ConceptSchemeContainment)
> >
> >
> > Hello,
> >
> > Following the discussion today I have the following action:
> >
> > > *[NEW]* *ACTION:* Antoine to summarise inScheme vs isDefinedBy and
> > > decide whether or not to reopen the issue. [recorded in
> > > http://www.w3.org/2007/10/30-swd-minutes.html#action03]
> >
> > Minutes of the Oct 9 Face-to-face meeting [1] present the
> > following (parts of a) resolution:
> >
> > > > 1. for historical reasons, inscheme is kept as a subprop of
> > > > isDefinedBy we agree 3. that deprecating skos:inScheme (using
> > > > approporiate owl
> > > > vocab) is part of the accepted proposal
> >
> > These extend Alistair's proposal for concept scheme semantics
> > [3], which is also part of the resolution:
> >
> > > The SKOS Primer also defines best practices for using
> > rdfs:isDefinedBy
> > > to explicitly state the relationship between a SKOS conceptual
> > > resource and the concept scheme in which it is defined.
> >
> > HOWEVER, it is questionable whether inScheme has an original
> > meaning compatible with rdfs:isDefinedBy
> >
> > As RDFS spec puts it [4]
> >
> > > |rdfs:isDefinedBy| is an instance of |rdf:Property|
> > > <http://www.w3.org/TR/rdf-schema/#ch_property> that is used to
> > > indicate a resource defining the subject resource. This
> > property may
> > > be used to indicate an RDF vocabulary in which a resource
> > is described.
> >
> > As SKOS core guide puts it [5]:
> >
> > > where you would like to assert that a concept is a part of a
> > > particular concept scheme, use the |skos:inScheme
> > > <http://www.w3.org/2004/02/skos/core/spec/#inScheme>| property,
> >
> > The two properties therefore seem to have different motivations:
> > rdfs:isDefinedBy is linked to the notion of definition,
> > skos:inScheme to the one of containment. Elisa has cited the
> > following in our last telecon:
> >
> > >  If it's at all helpful, the "formal" definition of a
> > "concept system"
> > > from ISO 1087 is "a set of concepts structured according to the
> > > relations among them".
> >
> > Furthermore, as SKOS spec [6] puts it:
> >
> > > A concept may be a member of more than one concept scheme.
> >
> > This could raise a problem: rdfs:isDefinedBy is not
> > functional so can point at several resources. But it is
> > expected that all these resources are expected to give a
> > description of the defined resource. I don't think this would
> > be the case for all the concept scheme a concept is member
> > of. A concept will be for sure defined in some concept
> > scheme, but I don't expect it to be defined in all the
> > concept schemes it belongs to.
> >
> > As a consequence, I PROPOSE TO RE-OPEN THIS ISSUE (which by
> > the way is not closed, cf [7]) and make the following
> > proposal for a resolution:
> >
> > RESOLUTION: skos:inScheme is not deprecated, skos:inScheme is
> > not a subproperty of rdfs:isDefinedBy. In accordance [3] can
> > be kept, but adding inScheme in the proposed vocabulary as
> > well as domain and range statements for this property. It
> > should also include the following
> > sentence: "The SKOS Primer also defines best practices for
> > using skos:inScheme to explicitly state the relationship
> > between a SKOS conceptual resource and the concept scheme(s)
> > to which it belongs."
> >
> >
> > Antoine
> >
> >
> > [1] http://www.w3.org/2007/10/09-swd-minutes.html
> > [2]
> > http://lists.w3.org/Archives/Public/public-swd-wg/2007Oct/0109.html
> > [3]
> > http://www.w3.org/2006/07/SWD/wiki/SkosDesign/ConceptSchemes/M
> > inimalProposal?action=recall&rev=1
> > [4] http://www.w3.org/TR/rdf-schema/#ch_isdefinedby
> > [5] http://www.w3.org/TR/swbp-skos-core-guide/#secscheme
> > [6] http://www.w3.org/TR/swbp-skos-core-spec/#inScheme
> > [7] http://www.w3.org/2006/07/SWD/track/products/3
> >
> >
> >
>
>

Received on Thursday, 8 November 2007 13:43:06 UTC