- From: Antoine Isaac <aisaac@few.vu.nl>
- Date: Thu, 16 Oct 2008 12:29:47 +0200
- To: Alistair Miles <alistair.miles@zoo.ox.ac.uk>, SWD WG <public-swd-wg@w3.org>, Sean Bechhofer <sean.bechhofer@manchester.ac.uk>
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. > ] 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. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > >
Received on Thursday, 16 October 2008 10:30:25 UTC