RE: [SKOS] RE : Skos mapping issues

Hi Antoine
re your points on skos:broader, in_scheme, mapping and KOS extensions:
 
We agree it is important to know that a concept, or KOS fragment, belongs to a particular scheme. Skos:inscheme appears a reasonable way of achieving this, within the constraints of a binary relational modelling framework like RDF. 
 
This is a separate issue from applicability of BT across schemes. We do see a difference in the semantics of an inter-vocab relationship from an intra BT within a vocab. 
 
In our view, there are 2 quite different kinds of relationship being discussed - local vocabulary extensions and inter thesaurus mappings between separate concept schemes (KOS).
 
To establish a BT relationship the child concept must fall entirely within the scope and context of the parent concept. When creating local vocabulary extensions, the new local concept scheme should fully align with the scope and context of the vocabulary being extended - as it is the intention to supplement the original with finer detail. In this case you might reasonably employ skos:broader in our view. The provenance (eg in-scheme) is still important - any local extension may be muddled/controversial etc and an application may decide not to make use of it.
 
This is not the same as inter thesaurus mapping though. There is likely to be an inherent mismatch in context and scope between 2 entirely separate KOS created for different purposes. A thesaurus (or related KOS) represents a particular perspective, considered useful for the various information retrieval purposes on a domain at a particular point in time. The concepts, the relationships between them and the language used to describe them are all contextually relative to the environment in which they are established. In this situation, we would argue that skos:broader should not be used as a mapping relationship between schemes and a different relationship should be used. There could for example be a set of skos mapping relationships, including say broader_mapping. We don't see that this creating any effective obstacle to semantic web applications but rather assisting with the semantics.
 
Returning to local vocabulary extensions, a fine point is that in_scheme identifies the origin of each concept - but does not identify the origin of each relationship. Is there any easy way for a local vocabulary to indicate that it is an extension of an earlier (larger) vocabulary? It will tend to be the case in Digital Library type applications that extensions are defined for some of the major de facto standard vocabularies.
 
Doug Tudhope & Ceri Binding
Hypermedia Research Unit
University of Glamorgan
 
 

________________________________

From: Antoine Isaac [mailto:aisaac@few.vu.nl]
Sent: Sun 29/07/2007 21:43
To: Tudhope D S (AT)
Cc: public-esw-thes@w3.org; public-swd-wg@w3.org
Subject: Re: [SKOS] RE : Skos mapping issues



Hi Doug,

> I tend to agree with Javier that it is important to be able to
> distinguish inter-thesaurus mappings from the standard intra thesaurus
> relationships. It's not clear to me that even the 'broader/narrower
> mappings' necessarily carry the same semantics, although there are
> some similarities.
> - As I see it, mappings usually carry a higher degree of uncertainty
> (and a lower confidence in any query expansion operations).

You might be right, even though in some cases, for query expansion, I
would rely more on a mapping (especially for equivalence) between
concepts from different thesauri than on an inter-thesaurus BT...

> - Another point is that dissolving boundaries between specific
> thesauri (and similar concept schemes) would be counter productive.
> They are created as a discrete entities, intended to be internally
> consistent for information retrieval purposes in a domain, although
> perhaps taking a particular view. So, while you may make additional
> mappings of different kinds between thesauri, its important to retain
> the integrity of concepts/relations belonging to the same scheme.

I understand your point, but I really don't like this. To having
skos:broader allowed between different concept schemes is an easy way to
create local vocabulary extensions, which will improve vocabulary
re-use, and hence bring more added value to the existing ones.
If we are to provide a format to port controlled vocabularies on the
semantic web then I would like not to prevent people in the future to
use these vocabularies in a semantic-web way!

Of course you could argue that this kind of link could be represented by
a property different from skos:broader. Do you think that the *semantic*
value (so, apart from e.g. consideration on editorial control) of a BT
'extension' link would be really different from a BT inside a vocabulary?

Antoine

PS: allowing for skos:broader between different concept schemes and
disconnecting the problem of the 'semantic value' of skos broader from
the one of concept scheme containement [1] are actually the reasons why
in other discussions I defend skos:inScheme. This property seems to me a
less constraining (and more explicit) option for representing provenance
and providing for some editorial control, even if it is not perfect...

[1] http://www.w3.org/2006/07/SWD/track/issues/36

> 
> Doug
>
> ------------------------------------------------------------------------
> *From:* public-esw-thes-request@w3.org on behalf of Antoine Isaac
> *Sent:* Mon 23/07/2007 08:10
> *To:* jlacasta@unizar.es; public-esw-thes@w3.org
> *Cc:* public-swd-wg@w3.org
> *Subject:* [SKOS] RE : Skos mapping issues
>
> [Sorry I skept the subject in previous posting]
>
> Hi Javier,
> >
> >
> >
> > Hi All,
> >
> > I am interested in the mapping of thesauri, so I have been reviewing the
> > documentation available in the SKOS-Project. It seems that there is
> three main
> > documents related with SKOS mapping in SKOS project [1,2,3].
>
> Oops now I've realized that it was not so smart of me to release 3,
> because I have missed 2. And there are indeed some similarities
> between the two, which is normal since I intended to make an account
> of a SWD discussion in which Alistair played an important role. Some
> synchronization should be done, so your discussion is useful (and my
> main intent behind [3] was also to revive this discussion :-)
>
> >
> > Each one present a quite different approach to mapping
> representation. The last
> > two documents it seems that try to simplify the skos mapping vocabulary.
> >
> > They map the partial and inexact equivalence relationships to other
> existent
> > relations in SKOS core. The partial relationship is mapped to
> skos:broader and
> > skos:narrower and the inexact is mapped or to skos:related or to a new
> > skos:overlappingConcept.
> >
> > I agree that the semantic of the partial equivalence relationship is
> equivalent
> > to the broader and narrower relationship. However, I think that the
> use of the
> > same property would difficult the identification of the mappings
> respect to the
> > basic ones.
>
> This is the crucial problem. The semantics are the same, so we should
> make them a same property.
> Ideally the identification problem is distinct (in our working group
> we recorded it as [5]), so it should not intefere.
> But of course in practice [5] is very difficult to solve in RDF, so in
> the end we might have to consider more than the semantics to define a
> property.
>
> > I think that at least the namespaces should be changed (e.g:
> > skosm.broader). This properties can be an specialization
> > of the basic ones. This would facilitate the separation of the
> mappings to the
> > core structure of each thesauri.
>
> Problem is that specializing skos:broader might collide with the need
> to identify a skos:broader statement in a scheme in a way similar to
> the one you want to identify a mapping. Some people (cf [6]) would
> like skos:broader statements to hold only between concepts from one
> scheme.
> I'm not a strong believer of this, but I certainly think that if we
> want to record mapping identification by creating a special property
> we should not make identification of intra-thesaurus links even more
> difficult than what it is now.
>
> >
> > I do not agree with the use of skos:related as inexact equivalence
> exposed in
> > [2]. I think they are different. An inexact equivalence indicates
> > that two concepts share some meaning and that not always happen with
> the more
> > general skos:related relationship.
> > A inexact equivalence relationship can be seen as an specialization of
> > skos:related given that indicate a relationship
> > between the concepts but not in the other way.
>
> +1
>
> >
> > Respect to the compositions of mappings through "and", "or" and "not"
> > relationships I think that to be able to create complex compositions as
> > (A and B and (C or (D and E))), it would be needed a specialization
> of skos
> > concept (called for example conceptCollection) to group all the composed
> > concepts and the type of composition.
> >
> > I see that there are some similarities in the "and" relationship
> respect to the
> > pre-coordination of labels in a thesaurus, and also
> > respect to the composition in USE relationship to refer from a
> complex label to
> > two simpler ones. However, I think they are
> > some semantic differences between the "and" and the coordination
> making them not
> > completely interchangeable.
>
>
> This was the point in [3] to treat this "and" problem in the context
> of a different coordination problem which is on the SWD agenda [4]
> Your point about "and" and pre-coordination is valid. There are case
> of complex mappings with conjunctions that could well correspond to
> post-coordination cases, and [4] is too narrow for this.
> So we should re-introduce post-coordination in the loop by means of
> some specific "and". Something which semantics should be roughly
> if x match (y andpostcoord z) then (if doc skos:subject x then doc
> skos:subject y and doc skos:subject z )
>
> I think it is still a good idea to separate it from pre-coordination:
> in my current view (and I learned a lot reading the wise posts of this
> list, and could continue learning)
> A mapping to a pre-coordination is a mapping to a single, even if
> complex, subject: the semantics would not imply infering new
> skos:subject triples. In this case the problem is delegated to [4]
> A mapping to post-coordination would involve several subjects, as
> mentioned in the previous rule
> Would such an approach alleviate your concerns?
>
> Best,
>
> Antoine
>
> >
> > [1] http://www.w3.org/2004/02/skos/mapping/spec/
> > [2] http://isegserv.itd.rl.ac.uk/public/skos/press/dc2006/mapping.html
> > [3]
> http://www.w3.org/2006/07/SWD/wiki/SkosDesign/ConceptualMapping/ProposalOne
> [4] http://www.w3.org/2006/07/SWD/track/issues/40
> [5] http://www.w3.org/2006/07/SWD/track/issues/47
> [6] http://www.w3.org/2006/07/SWD/track/issues/36
>