Re: Quick review of the BP doc

Hi Phil,
Thanks for the first review of the BP doc...
> 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.
Almost 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.
+1. I've updated to reflect this mention.
> 
> You may consider mentioning the EC's Joinup platform as a place to find
> vocabularies too (https://joinup.ec.europa.eu/catalogue/repository)
Added.
> 
> 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).

Done!
> 
> 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.
> 
TODO: We still have to merge your comments with Dave ones… More to come ;)

> 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)
> 
> 
updated! 
> 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.
> 

This reflects Dave comments…TODO: merge as well with Dave suggestions….
> 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).

The group decided to remove this section…. 

Thanks again Phil.

Cheers,
Ghislain


-- 
Ghislain Atemezing
EURECOM, Multimedia Communications Department
Campus SophiaTech
450, route des Chappes, 06410 Biot, France.
e-mail: auguste.atemezing@eurecom.fr & ghislain.atemezing@gmail.com
Tel: +33 (0)4 - 9300 8178
Fax: +33 (0)4 - 9000 8200
Web: http://www.eurecom.fr/~atemezin

Received on Thursday, 5 December 2013 14:43:26 UTC