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

RE: [SKOS] On ISSUE-71 ParallelMappingVocabulary and ISSUE-74 MappingPropertyConventions

From: Sini, Margherita (KCEW) <Margherita.Sini@fao.org>
Date: Mon, 18 Feb 2008 07:56:40 +0100
To: Antoine Isaac <aisaac@few.vu.nl>, SWD WG <public-swd-wg@w3.org>
Message-id: <BA453B6B6B217B4D95AF12DBA0BFB669029DAF56@hqgiex01.fao.org>

ok for me to keep the vocabulary for mapping parallel to the
vocabulary for semantic relationships.
 
Regards
Margherita
 
 

	-----Original Message----- 
	From: public-swd-wg-request@w3.org on behalf of Antoine Isaac 
	Sent: Sun 17/02/2008 23:33 
	To: SWD WG 
	Cc: 
	Subject: Re: [SKOS] On ISSUE-71 ParallelMappingVocabulary and
ISSUE-74 MappingPropertyConventions
	
	



	Dear all,
	
	I propose to OPEN ISSUE-71 ParallelMappingVocabulary [1] and consider
	CLOSEing it by the following proposal:
	
	RESOLUTION: The vocabulary for mapping links is parallel to the
	vocabulary for (paradigmatic) semantic relationships. It includes a
	skos:broadMatch, skos:narrowMatch and skos:relatedMatch which mirror
	skos:broader, skos:narrower and skos:related.
	
	This I think renders well the different discussions that took place
on
	the SKOS and SWD list, as well as previous mapping vocabulary
proposals,
	such as [2], which inspired I guess the design of the former SKOS
	mapping vocabulary.
	ISome more details: the text of [3] which we adopted as a resolution
for
	ISSUE-39 Conceptual mapping link [4,5] includes the following
	
	> Rather, it assumes that mapping links, as a parallel vocabulary to
the
	> SKOS semantic relations (see discussion
	>
<http://lists.w3.org/Archives/Public/public-esw-thes/2007Dec/0033.html>),
	> should somehow "inherit" the semantics of these relations. With the
	> fundamental difference that mapping does not come with the same
	> confidence and authority status than established semantic
relations.
	> For instance, a mapping statement may not be endorsed by the
	> creator(s) of the concepts that are mapped.
	
	This goes against ISSUE-71 [1] proposing the following option as an
	possible alternative to keeping the parallel vocabulary for mapping:
	
	> use skos:broader, skos:narrower and skos:related for
	> mapping, providing guidance
	
	I strongly disagree with it! It was precisely the reaction *against*
	using skos:broader/related/narrower for mapping which made me go for
	using parallel mapping vocabulary [3] (I was against it at the
	begining). I don't want us to lose time having again the same
discussion!
	
	Notice that one of the reason for refusing to use the paradimatic
	broader/narrower/related also for mapping is linked to fundamental
	considerations related to norm and authority.
	On the one hand, creating paradigmatic relationships such as
	skos:broader statement results from the core activity of KOS design,
	which is supposed to imply e.g. certain soundness properties for the
	resulting semantic network. Mapping is a different activity, where
the
	aim is not to create a new coherent KOS but to bridge two KOS with
	relationships that may be of different qualitative and authoritative
level.
	My understanding is that the semantic commitment (with respect to the
	original intended meaning of the linked concepts) is much stronger
when
	skos:broader than when using skos:broadMatch.
	I would consider that this typically happens because a mapping link
	between two schemes can be motivated by an application that has
	requirements which are completely different from each of the ones
that
	guided the design of each mapped scheme.
	
	This is completely different from the assumption Alistair presents in
[6]:
	
	> the current SKOS Reference WD assumes that
	> the main reason for having a "parallel" vocabularies for
	> broader/narrower/related is to provide a convenient mechanism for
	> distinguishing links between concepts within the *same* scheme from
	> links between concepts in *different* schemes.
	
	
	This is actually why in the Primer [7] we have allowed for the use of
	skos:broader *between* concept schemes and the use of skos:broadMatch
	*within* concept schemes. Because these relations are of different
	(epistemological??) level!
	
	Following this discussion, I would therefore make the following
proposal
	to OPEN ISSUE-74 MappingPropertyConventions and consider to CLOSE it
	with the following proposal:
	
	RESOLUTION: Even though it is acknowledged that SKOS semantic
relation
	properties will, in most applications, link conceptual resources that
	stand within a same scheme, nothing in the SKOS model prevents their
use
	for concepts from different schemes. Similarly, even though it is
	acknowledged that SKOS mapping relation properties will, in most
	applications, link conceptual resources coming from different concept
	schemes, nothing in the SKOS model prevents their use for concepts
that
	stand within a same scheme.
	
	Best,
	
	Antoine
	
	
	[1] http://www.w3.org/2006/07/SWD/track/issues/71
	[2] http://jodi.tamu.edu/Articles/v01/i08/Doerr/
	[3]
	
http://www.w3.org/2006/07/SWD/wiki/SkosDesign/ConceptualMapping/ProposalTwo?a
ction=recall&rev=5
	[4] http://www.w3.org/2006/07/SWD/track/issues/39
	[5] http://www.w3.org/2007/12/18-swd-minutes#item02
	[7] http://www.w3.org/2006/07/SWD/wiki/SKOS/DraftPrimer
	>
	> Dear all,
	>
	> I'm continuing to forward contributions from Alistair, in relation
to
	> [1] and to a mail that I will send next.
	> Antoine
	>
	> [1]
http://lists.w3.org/Archives/Public/public-swd-wg/2008Feb/0060.html
	>
	> ----
	> [ISSUE-74] http://www.w3.org/2006/07/SWD/track/issues/74
	> MappingPropertyConventions (RAISED)
	> [ISSUE-71] http://www.w3.org/2006/07/SWD/track/issues/71
	> ParallelMappingVocabulary (RAISED)
	>
	> Quick fix? No.
	>
	> [ISSUE-74] asks, what are the usage conventions for SKOS mapping
	> properties and SKOS semantic relation properties? [ISSUE-71] asks,
do we
	> need the properties skos:broadMatch, skos:narrowMatch and
	> skos:relatedMatch at all?
	>
	> These two issues go right to the heart of recommended usage for
SKOS
	> semantic relation and mapping properties. They are intimately
related,
	> as usage conventions for mapping properties depend on vocabulary
	> available, and vice versa. I suggest we open these ASAP, to give
time
	> for preparation and due consideration of alternatives.
	>
	> To give a little background, the current SKOS Reference WD assumes
that
	> the main reason for having a "parallel" vocabularies for
	> broader/narrower/related is to provide a convenient mechanism for
	> distinguishing links between concepts within the *same* scheme from
	> links between concepts in *different* schemes. This utility
obviously
	> depends on certain usage conventions being followed, i.e. that
	> skos:broader, skos:narrower and skos:related are *only* used to
link
	> concepts in the same scheme, and that skos:broadMatch,
skos:narrowMatch
	> and skos:relatedMatch are *only* used to link concepts in different
	> schemes. To restate the point, if these usage conventions aren't
	> followed, then the main raison d'etre for skos:broadMatch,
	> skos:narrowMatch and skos:relatedMatch falls apart.
	>
	> Note that [ISSUE-73] and [ISSUE-75] are both dependent on
[ISSUE-71].
	> [ISSUE-73] asks, which other properties is skos:exactMatch disjoint
	> with? [ISSUE-75] asks, which other properties can be involved in
	> property chain inclusions with skos:exactMatch? Both of these
questions
	> depend on the SKOS vocabulary recommended for mapping.
	>
	> Note also that [ISSUE-83] is closely related to [ISSUE-71] and
	> [ISSUE-74], because the proposed inference pattern depends on usage
	> conventions which are not yet established. However, I suggest we
	> consider [ISSUE-83] separately as a lower priority, because the
proposed
	> inference pattern can probably not be supported, regardless of our
	> decision on [ISSUE-74].
	>
	> [ISSUE-73] http://www.w3.org/2006/07/SWD/track/issues/73
	> [ISSUE-75] http://www.w3.org/2006/07/SWD/track/issues/75
	> [ISSUE-83] http://www.w3.org/2006/07/SWD/track/issues/83
	>
	>
	
	
	
Received on Monday, 18 February 2008 06:57:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:52 UTC