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

RE: [SKOS] TR : ISSUE 47 MappingProvenanceInformation

From: Sini, Margherita (KCEW) <Margherita.Sini@fao.org>
Date: Wed, 06 Feb 2008 05:09:49 +0100
To: Antoine Isaac <aisaac@few.vu.nl>, SWD WG <public-swd-wg@w3.org>, SKOS <public-esw-thes@w3.org>
Message-id: <BA453B6B6B217B4D95AF12DBA0BFB669029DAECD@hqgiex01.fao.org>
Thanks! The second solution seems good to me!
 
Regards
Margherita

	-----Original Message----- 
	From: Antoine Isaac [mailto:aisaac@few.vu.nl] 
	Sent: Tue 05/02/2008 19:51 
	To: Sini, Margherita (KCEW); SWD WG; SKOS 
	Cc: 
	Subject: [SKOS] TR : ISSUE 47 MappingProvenanceInformation
	
	

	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.
	
	>
	> 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.
	
	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 04:10:25 UTC

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