Re: [SKOS] RE : Skos mapping issues

Hi Doug and Ceri,

Thanks very much for your answer. Very useful!

Now if I understand we can say that between two schemes we have two kind 
of links (taking BT as a simplification)
1. standard BT, as in a simple thesaurus, that can be used for scheme 
extension. I agree with this: my criticism was on the your saying that 
skos:broader was an intra-thesaurus link while I also wanted to make use 
it as inter-thesaurus link ;-)
2. mapping BT, which has a fundamentally different meaning. Standard BT 
would imply strong agreement on the scope/domain of the concept scheme, 
giving a standard BT assertion all kind of normative effect on the 
meaning of the considered concepts, while BT for mapping could be much 
more lenient on this point. If we agree on this (and you're really not 
far from convincing me ;-) then it's true that the linking construct 
should be different, as it is the case in the original SKOS mapping 
vocabulary draft [1]

Now the point about  BT and provenance. Some people on the SWD and SKOS 
list argue for using skos:broader just inside a single concept scheme to 
ensure that there won't be amiguity on this point.
I find too constraining a stance, we should allow case 1 above. Yet, to 
answer your question, there is no direct way, if we allow for such 
inter-scheme skos:broader, to know that a given skos:broader corresponds 
to a scheme extension. You would have to query for the inScheme of both 
concepts, and see whether they are identical or not.
My position and that is that this trick is not difficult to implement, 
and its condition (having inScheme properly declared for the concepts) 
not difficult to ensure by giving proper guidelines. Provenance 
consideration shall not prevent us from using skos:broader between 
different schemes. I hope you agree with that...

Best,

Antoine

[1] http://www.w3.org/2004/02/skos/mapping/spec/


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

Received on Thursday, 2 August 2007 15:23:08 UTC