Re: ISSUE-164: new draft answer

Hi all,

Here's a new draft response to Doug on [ISSUE-164], which takes into 
account our latest discussion with Alistair. I propose we approve to 
send it at the next teleconference.

Antoine

--------

Dear Doug,

Thank you for your comment in [1], which is copied at the end of this mail.

Your remark on the respective emphasis given to KOS extension and KOS 
mapping is plain right. I think the WG indeed foresees more use cases 
for mapping than for extension, as it appears in the SKOS Use Cases and 
Requirements document [2].
Accordingly, your suggestion to change the order of the respective 
sections in the Primer will be implemented.
Further, we plan to add the two following scoping sentences to these 
sections.
For KOS mapping:
[
Mapping is expected to be crucial for applications that use several KOSs 
at a same time, where these KOSs have overlapping scopes and need to be 
semantically reconciled -- examples of such application can be found in 
the SKOS Use cases and Requirements document 
(http://www.w3.org/TR/skos-ucr/#R-ConceptualMappingLinks). A key feature 
of mapping is the possibility to state that two concepts from different 
schemes have comparable meanings, and to precise how these meanings 
compare, even though they come from different contexts and possibly 
adhere to different modelling principles.
]
For KOS extension:
[
Extension of a KOS can be especially useful when its designers (or third 
party KOS publishers) want to achieve a better coverage of a 
(sub-)domain, while adhering to the principles that guided the design of 
the existing KOS -- e.g., by re-using some of its concepts.
Explicit KOS extension and re-use can also be used as a modularization 
mechanim, when a family of articulated KOSs (or parts of an overarching 
vocabulary) is designed to cover several (sub-)domains, and its 
designers want to allow specific applications to operate on given 
selections of concepts.
]

Regarding your last comment on the potential problems raised by 
extension and inclusion of concepts in different schemes. There was some 
discussion between us about explicitly discouraging it. To leave the 
door open for innovative approaches and scenarios, we would like to keep 
to neither encouraging nor discouraging this practice. We really have 
almost no experience here, so we prefer to say nothing and let the 
community define best practice in response to implementation experience.
In fact if you believe this practice is potentially harmful, we 
encourage you to publish a brief best practice note and inform the SKOS 
community via the mailing list. We'd also be more than happy to set up a 
"SKOS community best practices" wiki page to collect links to such 
statements!

Finally, about your request for saying "something on how KOS developers 
might publish a vocabulary in SKOS, while asserting some practical form 
of ownership". I it is about the possibility to represent the provenance 
of statements that "compose" a KOS (e.g. the skos:inScheme statements), 
we unfortunately cannot propose an easy way for doing this for the 
moment. The resolution SKOS ISSUE-36 [3] gives hints about how this has 
been left to future implementations, e.g. using RDF named graphs. The 
Primer also touches the issue in section 3.1 (in "Note—owl:imports and 
re-using KOSs") [4]. We could however be more explicit, and propose to 
replace
[
If an application is concerned with provenance information, additional 
steps may be required in order to maintain the provenance of the 
imported triples. Such functionality is however currently outside the 
scope of SKOS.
]
by
[
If an application is concerned with practical provenance or ownership 
information, additional steps may be required in order to maintain the 
provenance or assert the authority of imported
triples, using for instance RDF named graphs. Such functionality is 
however currently outside the scope of SKOS.
]

I hope these modifications seem appropriate to you. Please do not 
hesitate to send further comments to this mail, your experience is 
really precious!

Best regards,

Antoine

[1] http://lists.w3.org/Archives/Public/public-swd-wg/2008Oct/0062.html
[2] http://www.w3.org/TR/skos-ucr/#Accepted
[3] http://www.w3.org/2006/07/SWD/track/issues/36
[4] http://www.w3.org/TR/skos-primer/#secscheme

> ISSUE-164: Extension vs mapping (SKOS Primer)
>
> http://www.w3.org/2006/07/SWD/track/issues/164
>
> Raised by: Antoine Isaac
> On product: SKOS
>
> Raised by Doug Tudhope in [1]
>
> Open world discussion and extension vs mapping in 3.1 and 3.2
>
> I’m a little concerned about the relative emphasis apparently given to extension
> vs mapping. The primer might be read as suggesting that the default way of
> connecting two KOS is via extension or direct linking, which I think would be
> inappropriate. While there are good cases for (third party) extending a KOS (eg
> by including local extensions), the wording in the intro to section 3 is perhaps
> a little enthusiastic and might run the risk of not sufficiently recognizing the
> potential problems of linking two different KOS. LIS experience has recognised
> that any major KOS represents a particular world view and that joining two
> different KOS in an effective manner is not necessarily straight forward. Hence
> the emphasis on distinct mapping relationships.
>
> Perhaps the editorial team could consider the appropriate order of the linking
> and mapping sections, whether more discussion on the rationale for mapping could
> be included, and whether some more guidance might be given on when to link and
> when to map.
>
> The linking example in section 3.1 brings up a currently somewhat problematic issue.
>   
> A new concept scheme can re-use existing concepts using the skos:inScheme
> property. Consider the example below, where a reference concept scheme for
> animals defines a concept for "cats":
>   
>
> However there is nothing to prevent a new developer attaching their own new
> concept to someone else's existing SKOS scheme and thus changing the scheme (if
> the links are followed). It would be bad practice but as far as I understand is
> possible. (A slight modification of the example in 3.1 illustrates the point below.)
>
> I appreciate this is integral to the open world model and in the long run, it
> might be addressed by mechanisms of assigning provenance to RDF (sets of)
> statements, development of trusted vocabulary registries, caution when importing
> a SKOS vocabulary, etc. In the near future, I believe that the majority of
> applications will be effectively closed world, in that they will create an
> in-house index or database based on selected resources from the Web (including
> linked data publications). Perhaps the SKOS primer might also address more
> immediate concerns of how a vocabulary provider might make their vocabulary
> available. Is it possible to say something on how KOS developers might publish a
> vocabulary in SKOS, while asserting some practical form of ownership?
>
> Apdx
>
> Eg A slight modification of the example in 3.1 if I understand it correctly
> ============= alt example (undesirable?)
> ex1:referenceAnimalScheme rdf:type skos:ConceptScheme;
>    dc:title "Reference list of animals"@en.
> ex1:cats rdf:type skos:Concept;
>    skos:prefLabel "cats"@en;
>    skos:inScheme ex1:referenceAnimalScheme.
>
> The creator of another concept scheme devoted to cat descriptions can freely
> include the reference ex2:abyssinian concept in AN EXISTING scheme, and then
> reference it as follows:
>
> ex2:catScheme rdf:type skos:ConceptScheme;
>    dc:title "The Complete Cat Thesaurus"@en.
>
> ex1:cats skos:inScheme ex2:catScheme.
>
> ex2:abyssinian rdf:type skos:Concept;
>    skos:prefLabel "Abyssinian Cats"@en;
>    skos:broader ex1:cats;
>    skos:inScheme ex1:referenceAnimalScheme.
>
>
>
>
>

Received on Friday, 17 October 2008 08:15:20 UTC