Add smarter statement linter

[no-reply]

Statements and their URIs have a number of clear "MUST" in the technical paper and some other implied requirements. We should be able to verify at least the following:

• Presence of:
  • a version number
  • exactly one skos:definition (per language)
  • at least one skos:scopeNote
• Trailing slash on URIs
• Matching dct:identifier with the one reflected in the statement URI
• Membership in a concept scheme with the same version
• Membership in a collection (is this required?)

Feel free to expand on this list in comments.

[aisaac]

Thanks for starting it!
The one I can think of right now is the presence of exactly one |skos:prefLabel| (per language)
There might be more, but I won't have time for this sort of investigation before ten days now, I'm afraid :-(

On 9/16/15 7:43 PM, Thomas Johnson wrote:

Statements and their URIs have a number of clear "MUST" in the technical paper and some other implied requirements. We should be able to verify at least the following:

• Presence of:
  o a version number
  o exactly one |skos:description| (per language)
  o at least one |skos:scopeNote|
• Trailing slash on URIs
• Matching |dct:identifier| with the one reflected in the statement URI
• Membership in a concept scheme with the same version
• Membership in a collection (is this required?)

Feel free to expand on this list in comments.

—
Reply to this email directly or view it on GitHub #23.

[anarchivist]

Membership in a collection (is this required?)

I think it's implicit, but I'd say yes (cc @musebrarian).

Other requirements:

• All members of a concept scheme must be represented within the Turtle
• All members of a collection must be represented within the Turtle
• If a language tag is used on any literal, it must be used consistently across all the statements (in other words, "partial translations" are not acceptable)

[anarchivist]

(I'd like @mzeinstra's and @aisaac's feedback on the last point in particular.)

[aisaac]

I agree with the need of avoiding partial translations, but it may be not trivial to check, for the case where we can have several statements of a same property applied to a right statement (would we count them and check the counts across languages?)

Antoine

On 9/16/15 10:41 PM, Mx A. Matienzo wrote:

(I'd like @mzeinstra https://github.com/mzeinstra's and @aisaac https://github.com/aisaac's feedback on the last point in particular.)

—
Reply to this email directly or view it on GitHub #23 (comment).

[no-reply]

(would we count them and check the counts across languages?)

I sense this is the best we could do. Taking @en as the expected number, and failing or warning if there is a different count of notes.

Alternatively, we could consider a translation "complete" if it has a prefLabel and a description. It might be useful to get feedback from the other group on this---how do we plan to manage translations?

[aisaac]

Could we just postpone it until the creation of translation becomes a more pressing issue, or should it be addressed right now?
On 9/16/15 10:59 PM, Thomas Johnson wrote:

(would we count them and check the counts across languages?)

I sense this is the best we could do. Taking |@en| as the expected number, and failing or warning if there is a different count of notes.

Alternatively, we could consider a translation "complete" if it has a |prefLabel| and a |description|. It might be useful to get feedback from the other group on this---how do we plan to manage translations?

—
Reply to this email directly or view it on GitHub #23 (comment).

[anarchivist]

I think it could be postponed, or at least separated from the more generalized need for a linter. I think there was some discussion about ensuring that the rights statement application would only serve up "complete" translations - so there needs to be some way for us to make that determination - or to guard that during the editorial process.

[no-reply]

👍 to postponing. It's a fairly minor issue, and it shouldn't be hard to come upon an answer once someone is actually working on translations.