- From: Thomas Baker <baker@sub.uni-goettingen.de>
- Date: Thu, 19 Mar 2009 09:27:14 +0100
- To: Antoine Isaac <aisaac@few.vu.nl>
- Cc: Alistair Miles <alistair.miles@zoo.ox.ac.uk>, SWD WG <public-swd-wg@w3.org>
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