Hi Antoine,
I'd rather not say anything at all. If we do, I think we're
overstretching. I suggest we niether encourage nor discourage this
practice. We really have no experience here, so better to say nothing
and let the community define best practice in response to
implementation experience.
If Doug believes this practice is potentially harmful, I encourage him
to publish a brief best practice note and inform the SKOS community
via the mailing list. I'd also be more than happy to set up a "SKOS
community best practices" wiki page to collect links to such
statements.
Practices for KOS linking would also be the subject of a very
interesting research paper :)
Cheers,
Alistair.
On Mon, Oct 13, 2008 at 08:20:09AM +0200, Antoine Isaac wrote:
> Hi Alistair,
>
> Thanks for your comments!
> About the part of my answer you find debatable:
>
>>> Regarding your last comment on the potential problems raised by
>>> extension and inclusion of concepts in different schemes, I'd propose
>>> the following note:
>>> [
>>> Note -- messing with existing KOSs. RDF provenance mechanisms may be
>>> used to track additions to a KOS that are not done by its original
>>> designers. However, such functionality is currently outside the scope
>>> of SKOS. Accordingly, this document encourages publishers of new
>>> SKOS concepts not to include them via skos:inScheme statements into
>>> existing KOSs that they do not not "own". In the above example, one
>>> should therefore not assert that ex2:abyssinian belongs to
>>> ex1:referenceAnimalScheme.
>>> ]
>>>
>>
>> I'm not sure about this. Just because SKOS does not deal with RDF
>> provenance, does not mean there aren't good solutions elsewhere. I
>> suggest not to include the last two sentences.
>>
>>
>>> Notice that this last note also adresses your request for saying
>>> "something on how KOS developers might publish a vocabulary in SKOS,
>>> while asserting some practical form of ownership". For the moment, we
>>> unfortunately cannot propose an easy way for doing this.
>>>
>>
>> ...but we encourage the community of practice to develop
>> solutions. SKOS can only go so far, the rest is up to the community.
>>
>
> I guess you're right, that people could one day use cool provenance
> mechanisms. However, Doug's comment was making much sense, and even with
> appropriate provenance mechanisms I do not think it is very good
> practice to include one's own concepts in someone else's concept scheme,
> when this someone else is likely not to have anticipated such an
> addition. Otherwise I'd feel it would be encouraging some cuckoo
> behaviour ;-)
>
> As a compromise we could soften the end of the note:
> [
> Note -- messing with existing KOSs. RDF provenance mechanisms may be
> used to track additions to a KOS that are not done by its original
> designers. However, such functionality is currently outside the scope of
> SKOS. Generally, this document thus encourages publishers of new SKOS
> concepts not to include them via skos:inScheme statements into existing
> KOSs that they do not not "own", unless they do so using mechanisms that
> allow distinguishing clearly the information they publish. In the above
> example, one should therefore not assert that ex2:abyssinian belongs to
> ex1:referenceAnimalScheme using a bare, provenance-neutral skos:inScheme
> triple.
> ]
>
> Would that be ok?
>
> Cheers,
>
> Antoine
>
>> Cheers,
>>
>> Alistair.
>>
>>
>>
>>> I hope these modifications seem appropriate to you. Please do not
>>> hesitate to send further comments, 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
>>>
>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
>
>
--
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