W3C home > Mailing lists > Public > public-gld-wg@w3.org > November 2013

Quick review of the BP doc

From: Phil Archer <phila@w3.org>
Date: Wed, 20 Nov 2013 11:57:38 +0000
Message-ID: <528CA3B2.4000406@w3.org>
To: Public GLD WG <public-gld-wg@w3.org>
Bernadette, Boris, Ghislain,

I'm reading through the BP doc and making notes as I go. I know you;re 
working on it actively so I'm not making edits just yet but I hereby 
offer to go through the doc and give it native-speaker polish when 
you're ready.

Meanwhile I note...

'How to find vocabularies' is where I think LOV should be rather than 
under 'Where to find existing vocabularies in datasets.' It's a 
catalogue of vocabularies, not of datasets that use them.

You may consider mentioning the EC's Joinup platform as a place to find 
vocabularies too (https://joinup.ec.europa.eu/catalogue/repository)

Under 'URIs for properties with non-literal ranges' you have
What it means: Name all properties as verb senses, so that triples may 
be actually read; e.g., hasProperty .

As an alternative, I offer:

Naming or properties and relationships
What it means: Name all properties that define a relationship between 
classes as verbs, e.g. hasProperty. Simple properties that take a 
literal value should be nouns.

Remove any and all "this section is (non) normative" labels since the 
doc is a Note (and therefore it's all non-normative).

Under multilingual vocabs I notice this recommendation: As a set of 
rdfs:label in which the language has been restricted (@en, @fr...). 
Currently, this is the most commonly used approach. It is also a best 
practice to always include an rdfs:label for which the language tag in 
not indicated. This term corresponds to the "default"language of the 

This is an area where we're not following our own advice. For the DCAT 
turtle file I didn't include a default set of labels although I was 
tempted to. The consensus seemed to support this (see 
BUT... if the MLW group tells us that we should include default labels 
(i.e. ones with no language tags) then I'll add them.

Under URI Design Principles you have "A URI structure will not contain 
anything that could change" which ends by linking to the Web Arch doc on 
URI Opacity ... and then you have a section on URI opacity. I'd say one 
or the other.

You may also consider referring to some work I and others did on this 
for the EC (http://philarcher.org/diary/2013/uripersistence/ - I promise 
it's stable but if you want to refer to the original PDF then of course 
you may at 

I suggest you don't refer to Http-range-14 by name in the last paragraph 
of that section. I would, however, explain what the TAG is.

The procurement checklist is very US-centric ('federal-wide') is the 
give away ;-) But the thing that's missing from the list is use of open 
standards. I would add:

* Does the software use open standards for data exchange?
* Is the service replaceable with a competing service with a minimum of 
disruption? (i.e. avoid vendor lock-in).

That's all folks.




Phil Archer
W3C eGovernment

+44 (0)7887 767755
Received on Wednesday, 20 November 2013 11:58:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:40 UTC