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:27:33 UTC