Re: [SKOS] "Mapping" vs "standard" relationships

Hi all,

Comments inline...

On Tue, Jan 13, 2009 at 11:23:59PM +0100, Thomas Baker wrote:
> In Washington, we resolved [4]:
> 
>     RESOLUTION: 1. keep the mapping vocabulary broadMatch,
>     narrowMatch, 2. broadMatch, narrowMatch, etc. are
>     rdfs:subPropertyOf broader, narrower, 3. there are
>     no semantic conditions on broadMatch, narrowMatch;
>     i.e. graphs 1-6 are all consistent, 4. there is some text
>     about cultural conventions explaining where we expect
>     broadMatch to be used, 5. by convention, mapping properties
>     are only used to link concepts in different schemes, 6. in
>     the Last Call WD we'll note that the mapping vocabulary
>     may be dropped
> 
> The discussion in Washington referred to four scenarios: KOS
> Description, KOS Mapping, KOS Extension, and KOS Enrichment
> [5].
> 
> SKOS Reference [6] currently says:
> 
>     SKOS Reference: The mapping properties skos:broadMatch,
>     skos:narrowMatch and skos:relatedMatch are provided as
>     a convenience, for situations where the provenance of
>     data is known, and it is useful to be able to tell "at
>     a glance" the difference between internal links within
>     a concept scheme and mapping links between concept schemes.
> 
> The position in SKOS Reference is in line with the Washington
> resolution, and I understood Alistair to say we should make
> no further commitment beyond this and let the difference
> between the mapping and standard relationships sort itself out
> in practice.  
> 
> I do not disagree, and I think SKOS Reference is appropriately
> vague on this issue.  As per point 4 of the resolution above,
> however, I think the Primer should provide a bit more guidance
> on where we expect the mapping properties to be used.

Up to here, I agree.

> I understand the Primer example above [1] to mean that given
> concept scheme A with concepts X and Y, a person other than the
> designer of concept scheme A who wants to assert relationships
> between X and Y would use the _mapping_ properties [3].  (I see
> that in [5], Alistair thought it might be more appropriate to
> use semantic relation properties for KOS enrichment.)  If so,
> then the essential difference between mapping and standard
> relationships would not seem to lie with whether or not the
> concepts are in the same scheme, but rather with the position
> of the person making the assertion with respect to the scheme.
> Hence my suggestion [7]:
> 
> > The argument could run as follows: Ideally, we should be able
> > to tell from provenance information who said what, but in
> > practice, Semantic Web data is often merged in simple ways that
> > obscure the origins of assertions.  The distinction between
> > "mapping" and "standard" relationships is one of etiquette --
> > directly asserting "standard" relationships sends the message
> > that the asserter considers herself qualified to define the
> > relationship in a standard way.  For everyone else, the polite
> > thing is to assert a "mapping" relationship.
> 
> If the criterion for using mapping as opposed to standard
> links has to do with whether the related properties are in the
> "same" or "different" schemes, I'm not sure what that means
> in situations of KOS enrichment (see above) or KOS evolution
> (where I may map to another concept using a mapping property,
> then later decide to incorporate it into "my" scheme).
> 
> I do not think that defining the difference in terms of
> standpoint of the asserter is incompatible with the minimal
> commitment made in SKOS Reference [6], but it seems easier
> to explain. 

Here's how I see it.

We have two general scenarios, KOS description and KOS mapping, which
are represented in our use cases document, which correspond to well
established practice in the real world, and which are therefore fairly
well understood.

For these two scenarios, we can state the following convention: when
describing the internal structure of a KOS, use skos:broader,
skos:narrower, skos:related; when mapping two different KOS that are
overlapping in scope, use skos:broadMatch, skos:narrowMatch,
skos:relatedMatch, skos:closeMatch, skos:exactMatch.

The other two general scenarios, KOS enrichment and KOS evolution, are
open research areas, where there are few if any published examples and
therefore no established best practice. For these scenarios, I think
it is inappropriate for us to try and establish best practice at this
stage. Even if we tried, I think it is unlikely we would reach
consensus. I therefore think we should *not* state any conventions
regarding these two scenarios.

After consideration, I think the Primer should limit itself to
providing examples and guidance for conventional KOS description and
KOS mapping only. If other scenarios are discussed, it should be
stressed that these remain open areas, where best practice has not yet
been established.

I would much prefer that KOS enrichment and KOS evolution were treated
in a separate Note, or better a research paper, where design patterns
and conventions could at least be explicitly proposed, as a foundation
for further discussion.

I.e. I think we should postpone the provision of guidance and examples
for any scenarios other than conventional KOS description and KOS
mapping.

Cheers,

Alistair

> [1] http://www.w3.org/2006/07/SWD/SKOS/primer/primer-20090113.html
> [2] http://lists.w3.org/Archives/Public/public-swd-wg/2009Jan/0033.html
> [3] http://lists.w3.org/Archives/Public/public-swd-wg/2009Jan/0037.html
> [4] http://www.w3.org/2008/05/06-swd-minutes.html
> [5] http://www.w3.org/2006/07/SWD/wiki/WashingtonAgenda/MappingIssues
> [6] http://www.w3.org/2006/07/SWD/SKOS/reference/20081001/
> [7] http://lists.w3.org/Archives/Public/public-swd-wg/2009Jan/0039.html

-- 
Alistair Miles
Senior Computing Officer
Image Bioinformatics Research Group
Department of Zoology
The Tinbergen Building
University of Oxford
South Parks Road
Oxford
OX1 3PS
United Kingdom
Web: http://purl.org/net/aliman
Email: alistair.miles@zoo.ox.ac.uk
Tel: +44 (0)1865 281993

Received on Friday, 16 January 2009 12:19:26 UTC