- From: Alistair Miles <alistair.miles@zoo.ox.ac.uk>
- Date: Thu, 16 Oct 2008 17:11:40 +0100
- To: Antoine Isaac <aisaac@few.vu.nl>
- Cc: SWD WG <public-swd-wg@w3.org>, Sean Bechhofer <sean.bechhofer@manchester.ac.uk>
On Thu, Oct 16, 2008 at 12:29:47PM +0200, Antoine Isaac wrote: > Hi Alistair, Sean > > OK, I'll do that. > Note that I think I will also add something in the Primer to (partially) > answer Dou'g comments on ownership. I'd propose this: > >> 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 of the imported triples, using for instance RDF named >> graphs. Such functionality is however currently outside the scope of >> SKOS. >> ] Looks good. You might also say something like "...additional steps may be required to maintain the provenance or assert the authority of imported triples..."? I'm a bit out of my depth here tho, I'm not provenance or authority expert. Cheers, Alistair. > > Not a big change, but at least the word "ownership" would appear in the > Primer, and a first hint at a solution would be mentioned. > > There is however a problem: when we decided on closing ISSUE-36, we had > a piece of text that was refering to named graphs explicitly, and also > SPARQL patterns. But now this does not appear any more in the Reference. > Maybe I've missed a further resolution on that point, but I guess that > closing an issue with a resolution that is not completely implemented in > our docs is not really good, is it? > > Antoine > > >> Hi Antoine, >> >> On Tue, Oct 14, 2008 at 02:57:53PM +0200, Antoine Isaac wrote: >> >>> Hi Alistair, >>> >>> OK, I had not really thought about the possibility to postpone things >>> for next future... >>> I think your mail would be actually a good answer to (this part of) >>> Doug's comments. >>> >>> If I sum up, the answer to Doug's original mail would be for the moment: >>> - the points that you approved in [1] >>> - something that I'd derive from your mail below >>> >>> Does this sound OK? >>> >> >> That sounds great. >> >> Cheers, >> >> Alistair. >> >> >>> Antoine >>> >>> [1] http://lists.w3.org/Archives/Public/public-swd-wg/2008Oct/0135.html >>> >>> >>>> 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
Received on Thursday, 16 October 2008 16:12:19 UTC