- From: Benedikt Kaempgen <kaempgen@fzi.de>
- Date: Thu, 12 Dec 2013 13:32:30 +0000
- To: Joćo Paulo Almeida <jpalmeida@ieee.org>, "Government Linked Data Working Group" <public-gld-wg@w3.org>
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]" im Auftrag von "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 >> > >
Received on Thursday, 12 December 2013 13:32:56 UTC