Re: Best Practices review

Hi Makx,
Great feedback, thank you very much.  

I agree with your pushback on HTTP URI's not being a serialization or syntax for LD -- not sure how that crept in but I took a double take too, so thank you for calling it out.

Boris/Ghis - I have the token to incorporate these changes Tuesday 12/17 by 12noon US ET.

Cheers,
Bernadette Hyland

On Dec 16, 2013, at 5:34 AM, Makx Dekkers <makx@makxdekkers.com> wrote:

> 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.

Noted.

>  
> 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”.

Noted.

>  
> In section 6, the phrase “personal identifiable information” is used as section title, while the text has “personallyidentifiable 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?

Noted.

>  
> 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)?

Noted.

>  
> 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 tohttp://www.w3.org/TR/webarch/#uri-opacity should be in the last box.

Noted.

>  
> 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?

No, follow your nose is certainly not discouraged!  Should be referenced.  

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

OK

>  
> That’s all from me. Hope this helps.
>  
> Makx.
>  
> Makx Dekkers
>  
>