Quick review of the BP doc

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 
vocabulary

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 
http://lists.w3.org/Archives/Public/public-gld-wg/2013Sep/0006.html). 
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 
http://joinup.ec.europa.eu/sites/default/files/D7.1.3%20-%20Study%20on%20persistent%20URIs_0.pdf)

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.

HTH

Phil.




-- 

Phil Archer
W3C eGovernment

http://philarcher.org
+44 (0)7887 767755
@philarcher1

Received on Wednesday, 20 November 2013 11:58:08 UTC