Best Practices review

Based on https://dvcs.w3.org/hg/gld/raw-file/default/bp/index.html,
version 16 December 2013.

 

In the scope section there is a list of syntaxes. I don't think HTTP
URIs is a syntax that Linked Data can be written in.

 

In the summary table in section 1:

 

*         in the cell Standard Vocabularies, the last sentence is
"Create vocabularies when required following best practices wherever
possible." I would suggest to delete the last two words so changing the
sentence to "Create vocabularies when required, following best
practices".

*         In the cell Announce, the second part of the sentence "have a
plan in place to support it over time" is not related to announcing. In
section 21, there is no further mention of such  longer-term support.
Maybe that issue would fit better in the next cell Social Contract which
already talks about maintenance?

*         In the cell Social Contract the sentence "Regular updates and
maintenance is a requirement" could say "Regular updates and maintenance
over time are important requirements" (the verb in plural)

 

In section 3, there is mention of "regulated facilities". That term may
not be familiar to some people - could there be an example? And I guess
that what is published is information about these facilities rather than
the facilities themselves.

 

Section 4 has some statements that sound slightly contradictory: 

*         "Modeling Linked Data requires representation of data objects"
versus "When modeling Linked Data, one is representing things" 

*         "Denormalizing data may be necessary ." and "Denormalizing
data . is appropriate"

The sentence "Linked Data can [be] and is used within government
agencies to improve data integration for related or complementary
information" seems to be a bit out of place in the section on modelling
and would maybe better fit in the section 18 on Publishing Data for
Access and Reuse?

 

Section 5 almost defines a basic application profile for metadata - in
my experience, not all of the descriptors mentioned here are available
under all circumstances. This could maybe be softened by replacing the
word "including" with "which may include".

 

In section 6, the phrase "personal identifiable information" is used as
section title, while the text has "personally identifiable information"
and the summary table in section 1 has "personal identifiable data".
This should be consistent. Maybe better to use a phrase like
"information that can identify individual persons". Other than that, the
fact that information "can potentially be misused" is sometimes used as
an argument not to publish any data at all, because there is always a
risk of misuse. It seems to me that the main reason of not doing it is
that publication of information that can identify individual persons is
often prohibited by law - although in some countries the publication of
some types of such information is a matter of transparency (such as
individual tax returns in Norway and Sweden). Maybe the best practice
should say that publishers should be careful in publishing this kind of
information and respect the applicable legislation?

 

Section 8 again groups HTTP URIs together with what are here called
"serializations". I don't think URIs are a serialization of RDF. (And
why is this list included twice, here and in the scope section)?

 

In section 9, the two boxes "A URI structure will not contain anything
that could change" and "URI Opacity" seem to make more or less the same
point. If you want to keep them separate, at least the reference to
http://www.w3.org/TR/webarch/#uri-opacity should be in the last box. 

 

In section 19, there is no mention of access to data by direct
resolution of URIs (the follow-your-nose principle), but only access
through APIs. Is such direct resolution discouraged?

 

The subject of section 23 (Stability Properties) is not in the summary
in section 1. Maybe the section could be called "Data stability"?

 

That's all from me. Hope this helps.

 

Makx.

 


Makx Dekkers