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

Hi There,

First of all sorry for my long silence since some time... I had a lot of
leaves to take  :)

I didn't read all past emails, but I may try to give comments for this topic:

- I agree with Alistar that the first paragraph seems a bit difficult. For me
is more clear the second one. However the first paragraph says in addition
that the mapping can be good for a specific user but not for the original
owner of a scheme... (as far as I understood)... for example X and Y from
scheme SC1 and W from scheme SC2... I may do X exactMatch SC2 but the owner
of scheme 1 may do not agree....

-  Based on this second paragraph in the primer I understand that we can use
the mapping properties both between schemes as well as intra-scheme... I
imagine and almost remember that this is probably already an old discussion,
but personally I find very useful the possibility to use specific
relationships (the mapping ones) to clearly identify that the mapped concepts
comes from different schemes... In fact eventually I could create new
relationships in my scheme children of (rdfs:subPropertyOf) the more generic
"skos:semanticRelation" to do intra-scheme mappings (and those may even be
veeery specific such as hasSimilarStructureWhenliquid -if it has sense-),
leaving the mapping one exactly to the purpose of the between-schemes
mappings.

However, if we use the full skos:concept URI for the mapping, then there are
no problems of using same relationships between schemes or intra-scheme...

Hope this helps
Margherita

-----Original Message-----
From: public-swd-wg-request@w3.org [mailto:public-swd-wg-request@w3.org] On
Behalf Of Thomas Baker
Sent: 13 January 2009 23:24
To: Thomas Baker
Cc: Antoine Isaac; Alistair Miles; SWD Working Group
Subject: [SKOS] "Mapping" vs "standard" relationships



All,

To keep momentum from the call...

The Primer [1], section 3.1, currently says:

      By convention, mapping properties are used to
      represent links that have the same intended meaning
      as the "standard" semantic properties, but with a
      different application scope. One might say that mapping
      relationships are less <em>inherent</em> to the meaning
      of the concepts they involve. From the point of view
      of the original designer of a mapped KOS, they might
      even sometimes be wrong.

      Mapping properties are expected to be useful in specific
      applications that use multiple, conceptually overlapping
      KOSs. By convention, mapping relationships are expected
      to be asserted between concepts that belong to different
      concept schemes. However, the use of mapping properties
      might also be appropriate in cases where someone other
      than its owner needs to enrich the semantic relationships
      within a particular concept scheme.

Alistair suggested dropping the first paragraph above [2]:

    >In fact, I would be tempted drop the first of these three paragraphs
    >altogether. If I had no prior knowledge of SKOS, I would find the
    >first two sentences ambiguous. The words "scope" and "inherent" are
    >particularly difficult here.  And I'm not sure what value the third
    >sentence adds. I.e. one hopes that cases where the KOS designer and
    >the KOS mapper completely disagree about the nature of a mapping link
    >would be very rare. A brief, casual mention such as this may leave the
    >wrong impression, e.g. that these cases could be quite frequent.

to which Antoine responded [3]:

    > In fact I expect that these cases would be quite frequent. If a KOS 
    > designer agreed that a mapping link between two concepts in her KOS fit
her 
    > intent when creating the KOS, she would have created it as a standard 
    > semantic relationship then, wouldn't she?

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.

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.  I think the Primer text should, at any
rate, echo the point in SKOS Reference about "situations where the provenance
of data is unknown".

Tom

[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

-- 
Tom Baker <tbaker@tbaker.de>

Received on Wednesday, 14 January 2009 16:42:58 UTC