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 Sunday, 29 July 2007 20:43:49 UTC