Re: [SKOS] SKOS Reference Editor's Draft 23 December 2007

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Miles, AJ (Alistair) wrote:
> Dear Vit, Quentin,
> 
> The first editor's draft of the SKOS Reference is now available from:
> 
> [1] <http://www.w3.org/2006/07/SWD/SKOS/reference/20071223>
> 

please find my review below. Let me know if you need any clarifications - I
wrote my comments down in a little bit hasty way so there may be some noise...

Cheers,
Vit


"""

SKOS Reference Editor's Draft (23 Dec 2007 version) review
==========================================================

Legend
- ------

(REC) in the beginning of a remark means that I consider the respective
text as a recommendation to be accepted or rejected as you wish. (SER)
means that the respective remark is more serious and should be reflected
in the document somehow (IMHO). (COM) means that the following text is
just a general comment with no request on an actual change of the
document.

General remarks
- ---------------

(SER) I wouldn't move or even tighten the stuff in Section 1.1 (as
suggested in the @@TODO tag) - it could be that some users/developers will
have a look primarily at the reference. In such case, a generic overview
could be quite good for them in order to get a grip with the whole idea
without switching to another document (they may not possibly want to
read at all).

(REC) Perhaps it would make sense to split Section 1.2 into two parts -
one part giving the generic overview of what is SKOS and the other one
elaborating the relation between SKOS and OWL. This seems to be clearer
from the conceptual point of view. The following sections (1.3 and 1.4
in the current document) can build on the "OWL" section then very
naturally.

(SER) The document mentions possibilities of several different design
patterns quite often. While I find this freedom generally very good, it
would be nice to have document(s) or section(s) of a document that
comprehensively discus major possible design patterns for certain
representative SKOS use cases or examples. Perhaps a section(s) dealing
with this could be included in the reference if such a material is not
already planned and being elaborated as a separate part of the SKOS Rec.

(COM) I see the section on SKOS extension best practices (referenced
presumably as a TODO part throughout the document) as an essential
part of the document, facilitating the adoption and understandability of
the SKOS idea and utilisation in practice.

(SER) Some motivations could be added to the parts describing issues
like (non-exhaustive list):
- - disjointness of skos:related with transitive closure of skos:broader
  (7.4),
- - non-transitivity of skos:broader (7.6.5),
- - allowed cycles in the hierarchical relation (7.6.7),
- - interactions between semantic and mapping relations (10.6.6)
- - ...
The current wording of these and similar parts gives enough information
for conforming implementations, however, some users could perhaps like
to know more on reasons of why this is defined so (I remember several
threads on the mailing list giving sufficient arguments for many
if not for all of these issues). Maybe such explanations could go (or
are even planned to go) to the Primer, however, some of them may be quite
formal, therefore they'd presumably fit more into the Reference...

Specific remarks
- ----------------

(SER) The title of the Section 6 - Documentation (Notes) - is a little bit
unintuitive and ambiguous - does it mean that the section is about
documentation, documentation notes, notes about documentation or that it
provides only some non-exhaustive notes on documentation of SKOS
knowledge bases?

(REC) The title of Section 9 - Collections (Grouping) - could perhaps be
extended in order to explicitly state what grouping is this section
about (presumably conceptual resources grouping).

(REC) A reference to a more formal definition of the OWA could be added
into the respective part of Section 1.4.

(REC) A reference to more particular examples of different design patterns
w.r.t. the Conceptual Resources and OWL Classes relation could be added
to Section 3.5.1 (if there is a SKOS Rec document with such examples
being worked out). This holds for other similar parts of the document
that are mentioning different possible design patterns (although it
seems that the authors are aware of the need of these references
according to some draft notes, I decided to explicitly mention this, just
for sure ;) ).

(REC) The example in Section 4.5 could perhaps be explained in some
additional prose.

"""

- --
Vit Novacek

SmILE group
Digital Enterprise Research Institute (DERI)
National University of Ireland, Galway
Lower Dangan
Galway, Ireland
Tel: +353 91 495738
Fax: +353 91 495541
Web: http://www.deri.ie/about/team/member/vit_novacek/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHh6hRc7uyClWR0g8RAh6+AJ4odtoB3btmdBrkMyT2QDwUXgDoeQCfYKTu
nMDUig4LLXYoMp6FrI9Fuwg=
=QhKb
-----END PGP SIGNATURE-----

Received on Friday, 11 January 2008 17:33:20 UTC