Re: Best Practices review

Thanks all for your comments!
Boris



On Thu, Dec 12, 2013 at 2:32 PM, Benedikt Kaempgen <kaempgen@fzi.de> wrote:

> Hi,
>
> Here some feedback to the Best Practices Document:
>
> Good work, I especially like the crosslinking with the Linked Data
> Glossary.
>
> Also the "Summary of Best Practices" is useful. However, I think it would
> be better both for potential GLD publishers and W3C people building on this
> work, to make more transparent how complete the WG thinks those chapters
> are.
>
> How about if all best practices mentioned in the "Summary of Best
> Practices" at least shortly indicate their completeness/readiness and links
> from those best practices (e.g., [1]) lead to existing chapters? In those
> chapters, one sentence about the possible intention would then make the
> document ideal for continuing work.
>
> One spelling error I noticed: "assocated with the data."
>
> I hope that helps.
>
> Since I am not sure whether I will make today's call: It was a big
> pleasure working with you all on bringing forward the publication of
> Government Linked Data. Thanks!
>
> Best,
>
> Benedikt
>
> [1] <https://dvcs.w3.org/hg/gld/raw-file/default/bp/index.html#SELECT>
>
>
> ________________________________________
> Von: João Paulo Almeida [jpandradealmeida@gmail.com]&quot; im Auftrag von
> &quot;João Paulo Almeida [jpalmeida@ieee.org]
> Gesendet: Donnerstag, 12. Dezember 2013 14:26
> An: Government Linked Data Working Group
> Betreff: Re: Best Practices review
>
> Dear All,
>
> Here goes some additional comments on the best practices document:
>
> With respect to sections 6 and 7, I found their role a bit confusing in
> the current text.
>
> This is because some criteria for vocabularies in section 6 are repeated
> in section 7 (with a different purpose).
>
> I would like to suggest to separate ³Requirements for Vocabulary Creation
> and Dissemination² (which would emphasize what vocabularies should look
> like if you are creating them), from ³Additional Vocabulary Selection
> Criteria² (which would emphasize what you should consider if you are
> looking for an existing vocabulary to reuse).
>
> I would suggest to present first ³Requirements for Vocabulary Creation and
> Dissemination² (an inversion in the current order).
>
> In ³Requirements for Vocabulary Creation and Dissemination² we would say
> things such as:
> A vocabulary must be documented
> A vocabulary should be self-descriptive
> A vocabulary should be described in more than one language
> A vocabulary should be accessible for a long period
> A vocabulary should have persistent URLs
> A vocabulary should provide a versioning policy
> A vocabulary should be published following available best practices
>
> but not:
> Vocabularies should be used by other data sets
> Neither:
> Vocabularies should be published by a trusted group or organization
>
> These last two comments would be in Vocabulary Selection Criteria.
>
> Instead of repeating the criteria from ³Requirements for Vocabulary
> Creation and dissemination², the section on ³Additional Vocabulary
> Selection Criteria² would just refer to the : Make sure that the
> vocabulary was created following the recommendations aboveÅ  and then add
> the other specific criteria concerning reuse (level of adoption,
> trustworthiness of publisher).
>
> (By the way "should² has not marked as special keyword in these lists.)
>
> For Section 7, I got confused with the 2nd box:
>
> "URIs for properties with non-literal ranges
> What it means: Name all properties as verb senses, so that triples may be
> actually read; e.g., hasProperty .²
>
> Is this in the right place? Is seems so unbalanced with respect to the
> other boxes.
>
> Regards,
> João Paulo
>
>
>
>
> On 5/12/13, 12:02 PM, "João Paulo Almeida" <jpalmeida@ieee.org> wrote:
>
> >Dear All,
> >
> >I have not finalized my review, but would like to provide my comments so
> >far (only up to section 5):
> >
> >There are some statements about the normative force of the "specification"
> >that do not seem to make sense if this is progressing towards a note.
> >(See, the first sentence in section 4.)
> >
> >However, I think that it still makes sense to use the keywords from
> >RFC2119 to define what conformance for vocabularies would mean.
> >
> >Currently, the text does not use this keywords and reads as follows:
> >
> >"A data interchange, however that interchange occurs, is conformant with a
> >vocabulary if:
> >it is within the scope and objectives of the vocabulary;
> >all classes and properties defined in the vocabulary are used in a way
> >consistent with the semantics declared in its specification;
> >it does not use terms from other vocabularies instead of ones defined in
> >the vocabulary that could reasonably be used."
> >
> >I would rephrase this into:
> >"A data interchange that is is conformant with a vocabulary:
> >MUST include data described with terms of the vocabulary in consistence
> >with the vocabulary's scope and purpose;
> >MUST respect the semantics of classes and properties as declared in the
> >vocabulary specification;
> >SHOULD NOT use terms from other vocabularies in place of the ones defined
> >in the vocabulary and that could reasonably be used."
> >
> >The same with the sentences about vocabulary profile. It currently reads:
> >"A vocabulary profile is a specification that adds additional constraints
> >to it. Such additional constraints in a profile may include:
> >a minimum set of terms that must be used;
> >classes and properties not covered in the vocabulary;
> >controlled vocabularies or URI sets as acceptable values for properties."
> >
> >We could say:
> >"A vocabulary profile is a specification that adds additional constraints
> >to it. A profile:
> >MAY define the minimum set of terms that must be used;
> >MAY add classes and properties not covered in the vocabulary;
> >MAY determine the use of controlled vocabularies or URI sets as acceptable
> >values for properties."
> >
> >I found the list under "5. Vocabulary Discovery Checklist" unbalanced. It
> >has some verbs (suggesting a checklist) but then suddenly "How to find
> >vocabularies" and  "Where..." appears in the list. I think this should be
> >harmonized.
> >
> >Best regards,
> >João Paulo
> >
> >
> >
> >
> >
> >
> >
> >On 4/12/13, 3:34 PM, "Dave Reynolds" <dave.e.reynolds@gmail.com> wrote:
> >
> >>Review comments on [1] as downloaded on 2013-12-04.
> >>
> >>These are mostly editorial comments, some are more substantial but none
> >>fatal.
> >>
> >># Overall
> >>
> >>The document is in much better shape that it was that last time I looked
> >>at it, well done! It does seem worth publishing as a working group note.
> >>
> >># Document structure
> >>
> >>The section numbering is odd. I suspect all the sections are intended to
> >>be at the same level but currently it comes out with 99% of the document
> >>as subsections of section 1 then the short "Stability Properties" as
> >>section 2.
> >>
> >># Abstract
> >>
> >>Reads oddly, three abstracts in one. Suggest just using the text of the
> >>later "Purpose of the document section" section.
> >>
> >>If you retain the current text then:
> >>   s/conventions through/conventions for/
> >>
> >># Scope
> >>
> >>The reference on RDF is given as RDF-SCHEMA which doesn't seem
> >>appropriate, suggest using RDF Concepts.
> >>
> >># 1. Summary of Best practices
> >>
> >>This section doesn't really line up that well with the things discussed
> >>in the document but on balance is probably better to have it than not
> >>have it, just.
> >>
> >>## Box "NOMINATE A PILOT"
> >>
> >>Suggest dropping. The linked section doesn't actually talk about
> >>nominating pilots and that's not always appropriate. People reading this
> >>document could be at many different stages in linked data publication
> >>experience.
> >>
> >>## Box "SERIALIZATION"
> >>
> >>"triplifaction" is not common terminology.
> >>
> >>The title and content imply just serialization whereas presumably you
> >>mean data conversion as well.
> >>
> >>Suggest:
> >>
> >>"""
> >>DATA CONVERSION Convert the sources data to a Linked Data
> >>representation. This will typically mean mapping the source data to a
> >>set of RDF statements about entities described by the data. These
> >>statements can then be serialized into a range of RDF serializations
> >>including Turtle, N-Triples, JSON-LD, (X)HTML with embedded RDFa and
> >>RDF/XML.
> >>"""
> >>
> >>## BOX DOMAIN
> >>
> >>s/on authoritative/on an authoritative/
> >>
> >># 1.3 Vocabulary Discovery Checklist
> >>
> >>This section seems weak but I can't think an easy way to improve it. I
> >>guess just leave it.
> >>
> >># 1.4 Using SKOS to Create a Controlled Vocabularly
> >>
> >>Out of place, this should come later after at least 1.6 (Vocabulary
> >>Creation) and probably after 1.7 (Multilingual Vocabularies).
> >>
> >>The box "It is a good practice to use SKOS in the following situations:"
> >>needs work. It mixes up indications when SKOS is appropriate (first 1-2
> >>bullets) with advice on how to do it (next 2-3 bullets) with something
> >>completely odd (last bullet).
> >>
> >>Suggest:
> >>
> >>"""
> >>SKOS is appropriate in the following situations:
> >>
> >>    * There is a need to publish a controlled list of terms or
> >>taxonomies having a special meaning for the domain.
> >>    * The complexity and formality of an OWL ontology is not appropriate
> >>  (for example the terms are not themselves entities that will be richly
> >>described).
> >>
> >>In creating a SKOS vocabulary bear the following good practice in mind:
> >>
> >>    * Make a clear distinction between the collections of concepts
> >>(ConceptScheme) and the different individual concepts.
> >>    * Define, when possible, a different namespace for each
> >>skos:ConceptScheme.
> >>    * Structure the concepts in the list using properties
> >>skos:hasTopConcept, skos:broader, skos:narrower.
> >>    * Consider defining a Class to represent all the skos:Concepts in
> >>your controlled list (this can facilitate declaration of properties that
> >>will use this list).
> >>    * Provide multilingual labels for the terms.
> >>"""
> >>
> >># 1.6 Vocabulary Creation
> >>
> >>The box on versioning policy talks about a best practices section on
> >>Versioning that no longer exists, suggest dropping the last sentence.
> >>
> >># 1.7 Multilingual Vocabularies
> >>
> >>s/represents the latest trend in/is an approach to/
> >>
> >>[Not sure judgements like "latest trend" are appropriate here.]
> >>
> >>s/ , , /, /
> >>
> >>s/morphosintactic/morphosyntactic/
> >>
> >># 1.8 Best Practice for Choosing Entity URIs
> >>
> >>The Q answer boxes are hard to read:
> >>  - Some boxes use "Q/Y/N" others use "Q/A" suggest standardizing on the
> >>former
> >>  - The nesting of questions in the second box in unclear, using braces,
> >>indenting or something to help people see which Q each N lines up with.
> >>
> >># 1.9 URI Design principles
> >>
> >>The final section on TAG advice is hard to read for anyone doesn't
> >>already know all about this, needs some rewrite.
> >>
> >>EXAMPLE 2 presumably shouldn't be called an "example", a Note? an advice
> >>box? Also drop the pre formatting, it doesn't print properly.
> >>
> >>Either drop the term http-range-14 or put that up front and explain it.
> >>
> >># 1.11 IRIS
> >>
> >>s/homegenic/uniformly/
> >>
> >># 1.13 Security and Hosting
> >>
> >>This whole section seems very related to the US Government specific
> >>process. It is not clear to me that it says anything specific enough to
> >>be useful in a non-US context.
> >>
> >>Suggest dropping most of the section and replace by a simpler statement
> >>to the effect that "that for specific data and organizations there may
> >>be particular security considerations, so involve appropriate advisors
> >>early on in the process. Detailed considerations of security issues are
> >>beyond the scope of this document"
> >>
> >>Dave
> >>
> >>[1] https://dvcs.w3.org/hg/gld/raw-file/default/bp/index.html
> >>
> >
> >
>
>
>
>
>