W3C home > Mailing lists > Public > public-swd-wg@w3.org > February 2008

Re: [SKOS] TR : ISSUE 47 MappingProvenanceInformation

From: Alasdair Gray <agray@dcs.gla.ac.uk>
Date: Wed, 06 Feb 2008 11:53:22 +0000
Message-ID: <47A99FB2.30003@dcs.gla.ac.uk>
To: Antoine Isaac <aisaac@few.vu.nl>
CC: "Sini, Margherita (GILW)" <Margherita.Sini@fao.org>, SWD WG <public-swd-wg@w3.org>, SKOS <public-esw-thes@w3.org>

Antoine Isaac wrote:
>
> Hi Margherita (I cc your mail to the SWD list),
>
> (And sorry Guus I promise this will be my only interfering with the 
> issue you've just seized from me ;-)
>
>> -------- Message d'origine--------
>>
>> De: public-esw-thes-request@w3.org de la part de Sini, Margherita (KCEW)
>> Date: mar. 05/02/2008 18:04
>> : public-esw-thes@w3.org
>> Objet : ISSUE 47 MappingProvenanceInformation
>>
>>
>> ISSUE just opened after today conference.
>> I would mention is very important for us because based on different 
>> needs we
>> may have different mappings.
>>
>
> That's indeed a very important motivation for such a requirement.
We believe this will also be true for the astronomy situation.
>
>>
>> I propose to assign a creator or owner to the mapping so to idenfity the
>> provenance. and again by reusing if possible something already 
>> existing e.g.
>> dc:author or dc:creator (forgot which one is).
>>
>>
>> Regards
>> Margherita
>
>
> The problem is that the issue may refer to indvidual "mapping 
> statements", e.g. [ex1:cat skos:exactMatch ex2:chat].
> So applying your solution is technically feasible, but would require 
> RDF reification. We are here in a situation very similar to ISSUE-36 
> regarding containment of semantic relationships in concept schemes.
> And since RDF reification is not popular, we cannot go for this solution.
We had been thinking of this only on a set of mappings level so far, but 
you make a valid point that it could be on an individual mapping basis.

Alasdair
>
> Indeed, two solutions are possible:
> 1. Creating a kind of "mapping scheme", that could be treated as an 
> RDF named graph. Knowing that a specific MappingScheme object has for 
> instace ex:margherita as dc:creator and that it is the context in 
> which the mapping [ex1:cat skos:exactMatch ex2:chat] was asserted, 
> then you could by using appropriate SPARQL queries retrieve your 
> provenance information. This is very similar to the solution we 
> accepted for ISSUE-36 [1]
>
> 2. Creating a kind of "reification" for the mapping, similar to the 
> pattern Alistair used for ISSUE-26 [2]
> Instead of [ex1:cat skos:exactMatch ex2:chat] (or complementary to it) 
> we would assert the following triple
> _:b1 rdf:type MappingRelation;
>  skos:mappedConcept1 ex1:cat;
>  skos:mappedConcept2 ex2:chat;
>  skos:mappingRelationType skos:exactMatch;
>  dc:creator ex:margherita.
>
> This is actually what is done in current ontology alignment community, 
> e.g. the format used for the OAEI evaluation campaigns [3, 4-p5], 
> which introduces mapping "cells". These cells are gathered in 
> "alignments" using simple RDF statements. Conitnueing my fictional 
> SKOS namespace (but everything can be represented using the vocabulary 
> from [3])
> ex:myMappingScheme rdf:type skos:MappingScheme;
>  skos:includesMapping _:b1.
>
> Notice that the two solutions have their strong and weak points:
> - 1 is closer to the way SKOS paradigmatic relationships are 
> expressed, but is less flexible in terms of representation: things 
> will become messy if "mapping schemes" aggregate mappings from various 
> origins
> - 2 is more powerful at representing provenance information (you can 
> distinguish between the creator of the "mapping scheme" and the 
> creator of each mapping statement), but has clearly a technical flavor 
> (far from the way SKOS models its semantic relationships)
>
> Best,
>
> Antoine
>
> [1] http://www.w3.org/TR/skos-reference/#L9287
> [2] http://www.w3.org/TR/skos-reference/#L2914
> [3] http://oaei.inrialpes.fr/2007/
> [4] http://gforge.inria.fr/docman/view.php/117/251/align.pdf
>
>>
>>
>>
>>
>>
>
>
>
>
Received on Wednesday, 6 February 2008 11:52:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:31:48 UTC