RE: Last Call: SKOS Simple Knowledge Organization System Reference; SKOS Primer updated [ISSUE-164]

Hi Antoine
 
thanks for getting back
yes, I am happy with the proposed changes (including third one on RDF named graphs, tho see comments below)
 
minor copy edits:-
-- at a same time --> at the same time
-- and to precise how these meanings --> and to make precise how these meanings
-- I wasn't totally sure what was meant by 'modularization mechani[S]m' although I think I got the general idea.
Eg I wasn't sure in 'allow specific applications to operate on given selections of concepts'  precisely what they would do.
(Apologies if I'm being obtuse!) I guess its meant that the specific applications would extract out the selections [micro-thesauri?] and work with just those selections?

> 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.
yes I see the point. I'll probably wait and see what practices emerge before attempting any 'note'. 
A "SKOS community best practices" wiki page sounds like a good idea.
 
> We could however be more explicit, and propose to replace
The change to mention RDF named graph seems sensible. 
I'm not very familiar with this but does it perhaps apply beyond an immediate context of owl:imports 
to sets of RDF statements more generally, such as the example at top 3.1. 
Does the wording mean to imply a necessary association with owl:imports?
 
By the way, was there a definitive resolution to
'The resolution SKOS ISSUE-36 [3] '
I failed to find it in a quick browse of http://www.w3.org/2006/07/SWD/track/issues/36
but maybe I'm not familiar with the lay out and am overlooking it.
Could you maybe email the text or a direct link?
 
cheers
 
Doug

________________________________

From: Antoine Isaac [mailto:aisaac@few.vu.nl]
Sent: Tue 21/10/2008 21:37
To: Tudhope D S (AT)
Cc: public-swd-wg@w3.org
Subject: Re: Last Call: SKOS Simple Knowledge Organization System Reference; SKOS Primer updated [ISSUE-164]




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

[ISSUE-164] http://www.w3.org/2006/07/SWD/track/issues/164
[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
> Congratulations on a fine piece of work!
>
> Some relatively minor comments
>
> --- On the SPEC
>
> 1. SKOS Collections
>
> While SKOS collections represents best practice in thesaurus
> construction, many prominent existing thesauri (and related KOS) do
> not follow the SKOS collections semantics. Instead, they model guide
> terms, facet indicators etc as part of a hierarchy using standard
> Broader/Narrower relationships. This creates a problem in converting
> such existing KOS into SKOS. From discussions it appears other people
> have come to a similar judgment in converting such cases to SKOS -
> being reluctant to change the existing structure of a KOS designed by
> a third party. The pragmatic decision is often to create a (nonSKOS)
> property of a concept, to say essentially, 'NOT_FOR_INDEXING'. This
> allows a basic distinction to be made between a facet indicator (or
> guide term) and a concept available for indexing.
>
> Can we consider if something like this could be introduced into SKOS
> to facilitate conversion of many legacy KOS? The primer can always
> encourage the full collections approach as best practice.
>
> Other
>
> I think the treatment of SKOS Broader and broaderTransitive is a good
> flexible solution.
>
> --- Comments on the documentation:-
>
> REFERENCE
>
> 2. In section 1.3, as well as the cost/benefit argument for SKOS (in
> KOS versus a formal ontology), I think it is also possible to make an
> argument based on intended purpose. Some KOS (by design) do not
> represent a 'logical' view of their domain and are only converted to a
> formal logic representation in practical terms by changing their
> intended purpose.
>
> Other
>
> Does the Reference deal with SKOS specialisation (I see the Primer does)?
>
> PRIMER
>
> 3. possible typo in 2.3.1 Note-not transitive vs. intransitive:
>
> I'm not sure this says what is intended? There seem to be too many
> double negatives in sentence quoted below
>
> "Not specifying skos:broader as transitive implies that no new
> skos:broader statement cannot be inferred between cats and animals by
> applying SKOS semantics. "
>
> 4. 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 <http://www.w3.org/TR/skos-reference#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 <mailto:>.
> ex1:cats rdf:type skos:Concept;
> skos:prefLabel "cats"@en <mailto:>;
> 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 <mailto:>.
>
> ex1:cats skos:inScheme ex2:catScheme.
>
> ex2:abyssinian rdf:type skos:Concept;
> skos:prefLabel "Abyssinian Cats"@en <mailto:>;
> skos:broader ex1:cats;
> skos:inScheme ex1:referenceAnimalScheme.
>
> regards
>
>
> Doug
>
> Douglas Tudhope
>
> Professor, Faculty of Advanced Technology
>
> University of Glamorgan
>
> Pontypridd CF37 1DL
>
> Wales, UK
>
> Tel +44 (0) 1443-483609
>
> Fax +44 (0) 1443-482715
>
> dstudhope@glam.ac.uk
>
> http://hypermedia.research.glam.ac.uk/people/tudhope/
>
> Editor : The New Review of Hypermedia and Multimedia
>
>
> ------------------------------------------------------------------------
> *From:* public-esw-thes-request@w3.org on behalf of Alistair Miles
> *Sent:* Thu 04/09/2008 16:35
> *To:* public-esw-thes@w3.org
> *Subject:* Last Call: SKOS Simple Knowledge Organization System
> Reference; SKOS Primer updated
>
>
> The W3C Semantic Web Deployment Working Group is pleased to announce the
> publication of a Last Call Working Draft for the Simple Knowledge
> Organisation System Reference (SKOS):
>
> http://www.w3.org/TR/2008/WD-skos-reference-20080829/
>
> Our Working Group has made its best effort to address all comments
> received
> to date, and we seek confirmation that the comments have been addressed to
> the satisfaction of the community, allowing us to move forward to W3C
> Candidate Recommendation following the Last Call process.
>
> The Working Group solicits review and feedback on this draft
> specification.
> In particular, the Working Group would be keen to hear comments regarding
> any features identified at risk, and from those implementing (among
> others):
>
> * Editors: editors that either consume or produce SKOS;
>
> * Services: vocabulary services that provide access to vocabularies using
> SKOS;
>
> * Checkers: applications that check whether the constraints on SKOS
> vocabularies have been violated.
>
> Comments are requested by 3 October 2008, at which time the Working Group
> intends to close Last Call. All comments are welcome and should be sent to
> public-swd-wg@w3.org; please include the text "SKOS comment" in the
> subject
> line. All messages received at this address are viewable in a public
> archive.
>
> The Working Group intends to advance the SKOS Reference to W3C
> Recommendation after further review and comment. This Last Call Working
> Draft signals the Working Group's belief that it has met its design
> objectives for SKOS and has resolved all open issues.
>
> The Working Group has also published an update of the companion SKOS
> Primer:
>
> http://www.w3.org/TR/2008/WD-skos-primer-20080829/
>
> The Working Group expects to revise this Primer while the SKOS
> Reference is
> undergoing review and eventually publish the Primer as a Working Group
> Note.
>
> Please see also:
>
> http://www.w3.org/TR/2008/WD-skos-reference-20080829/#status
> http://www.w3.org/TR/2008/WD-skos-primer-20080829/#Status
>
> Kind regards,
>
> Alistair Miles
> Sean Bechhofer
>
> --
> 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
>
> --
> Sean Bechhofer
> School of Computer Science
> University of Manchester
> sean.bechhofer@manchester.ac.uk
> http://www.cs.manchester.ac.uk/people/bechhofer
>
>
>