Re: [SKOS] SKOS ontology sanity-check?

On Sun, Mar 15, 2009 at 04:40:49PM +0100, Antoine Isaac wrote:
> Following the decision we made at last telecon, 
> >[NEW] ACTION: Antoine to amend the labels and other annotations in
> >skos rdf in consultation w/ sean [recorded in
> >http://www.w3.org/2009/03/10-swd-minutes.html#action03]
> 
> I have now implemented my own comments [2] on the SKOS RDF file [1].
> 
> The new version is at [3]. The diff is at [4]. I have also attached my 
> original comments below, and reported on what I have done for each of them.
> 
> Comments are of course welcome!
>
> Note I have *not* modified the DL version of the SKOS schema at [5].

Antoine,

I'm not clear on the intended status of the DL schema. Where is
it linked from, if at all?

> PS--additional editorial notices: I have not added myself explicitly as a 
> dct:contributor, even if I changed the file, thinking that the editors 
> should be only judges of that kind of thing. But I'd like to mention the 
> case of Dave Beckett and Nikki Rogers, who are still listed as 
> contributors. I think they've contributed heavily to the first version, and 
> would indeed deserve being credited. But are they aware of (and supporting) 
> the modification of their work?

Could someone perhaps drop them a line?

Further comments interspersed below. I think the issue of
definition style is not insignificant, as SKOS could serve as an
example for many other vocabularies.

Tom

[1] http://dublincore.org/documents/dcmi-terms/#terms-creator

> 
> [1] http://www.w3.org/2006/07/SWD/SKOS/reference/20081001/skos.rdf
> [2] http://lists.w3.org/Archives/Public/public-swd-wg/2009Mar/0012.html
> [3] http://www.w3.org/2006/07/SWD/SKOS/reference/20090315/skos.rdf
> [4] http://www.w3.org/2006/07/SWD/SKOS/reference/20090315/diff-skos.txt
> [5] http://www.w3.org/2006/07/SWD/SKOS/reference/20081001/skos-dl.rdf
> 
> >=============== general comments
> >
> >*Dublin core namespace:*
> >The new DC namespace http://purl.org/dc/terms/ is introduced as 
> >namespace in the ontology, but only the legacy one 
> >(http://purl.org/dc/elements/1.1/) is used. To keep consistency with the 
> >Primer (which was moved from dc: to dct: after a comment from Tom) I 
> >would suggest move to the new one. Note that this comment partly applies 
> >to the Reference document: it uses dc:title in section 1.3, but never 
> >defines the DC namespace. Maybe this is the opportunity to position this 
> >title in the dct namespace.
> 
> Replaced dc: by dct: and removed definition of dc: namespace from rdf:RDF 
> header.

Note that (most of) Dublin Core properties in
the dct: (http://purl.org/dc/terms/) namespace
have formal ranges, whereas for properties in dc:
(http://purl.org/dc/elements/1.1/), range remains unspecified.

In particular, dct:contributor and dct:creator have the
non-literal range dct:Agent [1], so one would expect the object
to have a foaf:name or rdf:value.

dct:title has a literal range, so no problem there.

> >*Labeling:*
> >we have to live with the legacy URI local names, despite the fact that I 
> >personally find them horrible :-)
> >But are we forced to use the same (lack of) policy for the natural 
> >language rdfs:labels? 
> 
> Modified a number of labels, keeping to the upper case convetion for 
> classes and lower case convetion for properties.
> Shortly, I added verbs and articles that clarifies the semantics of the 
> *object* properties (expecially their direction). I believe that other 
> properties' labels have a clearer meaning, related to their domains and 
> ranges being "asymetric" from a representational perspective.

Hmm - I had always assumed that the upper/lowercase
convention applied only to the "names" of properties and
classes -- the bits that are concatenated with the base
URI of the namespace to form a URI for the property or
class. It never occurred to me that this convention might
extend as well to the human-readable labels, e.g. from
http://www.w3.org/2006/07/SWD/SKOS/reference/20090315/diff-skos.txt:

    <rdfs:label xml:lang="en">Concept</rdfs:label>
    <rdfs:label xml:lang="en">is in scheme</rdfs:label>

I should think we would want the labels all to be consistently
in uppercase or in lowercase (I'd vote for upper).

> >inScheme:
> ><skos:definition xml:lang="en">A concept scheme in which the concept is 
> >included.</skos:definition>
> >-> <skos:definition xml:lang="en">Relates a resource (for example a 
> >concept) to a concept scheme in which it is included.</skos:definition>
> >(the domain has been updated since SKOS 2004, and I don't like a 
> >definition that may be read as "inScheme is a concept scheme")
> 
> Done.

Hmm. To take two examples, foaf:name is defined as "A name for
something" and dct:title is defined as "A name given to the
resource -- they are defined in terms of their range, not in
terms of what they do, e.g.: "Relates a resource to a name given
to the resource". I see arguments both ways but think we should
pause to consider whether we want to adopt, in effect, a new
style for definitions.

Either way, the problem with changed domain remains.  Maybe:
"A concept scheme in which the resource is included"?

> >hasTopConcept:
> ><skos:definition xml:lang="en">A top level concept in the concept 
> >scheme.</skos:definition>
> >-> <skos:definition xml:lang="en">Relates, by convention, a concept 
> >scheme to a concept which is topmost in the broader/narrower concept 
> >hierarchies for that scheme, providing an entry point to these 
> >hierarchies.</skos:definition>
> 
> Done.

Ditto.

> >broader:
> ><skos:definition xml:lang="en">A concept that is more general in 
> >meaning.</skos:definition>
> >-> <skos:definition xml:lang="en">Relates a concept to a concept that is 
> >more general in meaning.</skos:definition>
> 
> Done.

Ditto - also for narrower, related, member...

-- 
Tom Baker <tbaker@tbaker.de>

Received on Thursday, 19 March 2009 08:27:55 UTC