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

Hi Alistair,

I don't see a real opposition here, unless Tom did really intend to discuss evolution and enrichment in the Primer: to me the core of his proposal lies in the paragraph:

>> > 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.

which I agree with, even though the appropriate wording for the Primer might be difficult for me to find :-/

Such a paragraph is I think rather agnostic towards promoting KOS evolution and enrichment as full-fledge scenarios. Note that like you, I would be actually uncomfortable with extensively discussing KOS evolution and enrichment in the Primer.
As a matter of fact, the only mention of these in the Primer is:

> 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.

Do you think that sentence is too strong? For me it's a relatively open sentence, in line with what you propose -- it is not *discussing* the scenario. IMHO, doing more than using this "might" (even if to say explicitly that this is an open scenario) could actually puzzle the reader by giving more importance to these potential "cases" than what is required.

So my concrete proposal would be:

1. Replace the last two sentences of 
[[
> 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 inherent 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.
]]
by something that would follow Tom's line in the abovementioned paragraph, and nothing more.

2. Keep the following paragraph:
[[
> 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.
]]
as such.

Is that compatible with your position? 

Cheers,

Antoine



> 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
>

Received on Tuesday, 20 January 2009 10:36:39 UTC