[SKOS] Closing ISSUE 47 MappingProvenanceInformation

Dear all,

My mail [1], considering that solution 1 of [2] is more convenient than 
solution 2, argues for the following resolution:

RESOLUTION: Provenance of mappings is not handled by the introduction of 
specific SKOS vocabulary. In the SKOS reference documents (Reference and 
maybe Primer), SKOS users are instead pointed at standard RDF 
containment mechanisms. The following text may be adapted in these documents
"An example solution to keep track of provenance of mappings is to coin 
a URI for the information source which publishes these mappings, and use 
it as a Named Graph URI. This URI can be used to describe (via RDF 
triples) meta-data on the set of mapping relationships published, such 
as their creator. Similar to what is done for retrieving the containment 
of paradigmatic relationships in a specific concept scheme, the URI of 
the information source can be then used in a SPARQL query with named 
graph clause, to establish the containment in this information source 
for a mapping relationship."



[1] http://lists.w3.org/Archives/Public/public-swd-wg/2008Feb/0063.html
[2] http://lists.w3.org/Archives/Public/public-swd-wg/2008Feb/0017.html
> Dear all,
> I would like to make the following proposal for ISSUE-47 
> MappingProvenanceInformation
> Proposal: considering that ISSUE-71 is CLOSEd by a resolution that 
> adopts a mapping vocabulary that parallels the SKOS paradigmatic 
> relation vocabulary (following e.g. 
> http://lists.w3.org/Archives/Public/public-swd-wg/2008Feb/0062.html), 
> we CLOSE ISSUE-47 by adopting the Solution 1 from 
> http://lists.w3.org/Archives/Public/public-swd-wg/2008Feb/0017.html
> My motivation is quite simple: if we go for the reification of mapping 
> relationships (the solution 2 of [1]), then we are not really 
> parralel. The way mapping relationship and paradigmatic ones would be 
> represented would actually be very different!
> Further, I truly believe that solution 2 is very technical and fits 
> more the requirements of the ontology alignment community. For more 
> general SKOs purposes, it may be enough to consider mappings on a set 
> basis. For instance, Alasdair, in the mail below, had not thought 
> about the "individual provenance" requirement at a first glance. I 
> would expect this requirement to be very rare in SKOS use cases.
> Best,
> Antoine
> [1] http://lists.w3.org/Archives/Public/public-swd-wg/2008Feb/0017.html
>> 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 Tuesday, 19 February 2008 18:44:26 UTC