Review of example data in BP8 and BP9

Hi everyone,

Today I got an action dwbp-ACTION-236: Review the vocabulary aspects of bp9
http://www.w3.org/2013/dwbp/track/actions/236

Actually I've done a bit more, i.e. check for both BP8 and BP9 at
http://w3c.github.io/dwbp/bp.html#VersioningInfo
because the example of one very much builds on the example of the other, and the issues I've spotted apply to both.
I'm also extending my feedback as a general feedback on the data that is in the example, i.e. how the vocabularies are used.

1. The namespaces MUST be documented somewhere, either at level of individual BPs or the whole BP document.
Where are these elements coming from?
PAV refered is refered in BP8 (but not BP9 btw)
I cannot be sure where version:VersionedThing is coming from...


2. version:VersionedThing is probably useless, and maybe even harmful.
What counts in the example is the concrete versioning statements in the description, not the fact that something is declared as versioned. Everything is potentially a versioned thing, I don't like our BPs to make recommendation that would be suggesting extra statement on every dataset for little added value. The BP can live very well without it.
It's a bit like prov:Entity. I actually dislike it a lot, because it doesn't say anything on the typed resource. But I can see more reasons to keep it.
There's also some apparent problem in the way it's used. timetable-001 is an instance of version:VersionedThing, and timetable-002 is an instance of version:Version? How come, given that both resources seem quite analogous?
Given that there is uncertainty on the provenance of this class (see point 1), I would strongly argue to remove all this altogether.


3. OWL has owl:versionInfo, which should be used instead of pav:version.
I think I like using several properties from PAV, but the OWL namespace is more 'W3C-official' than the PAV one.
And BP8 mentions explicitly OWL as a source of annotation properties for versioning (but then it uses none in the example!)


4. The dates are the same for dct:issued and dct:modified. This is not wrong data: it actually occurs a lot. But for an example in a section on time versioning, it kind of misses its point and may confuse readers.


5. Because I still don't know what version:currentVersion really is, I'd recommend to use something else. Or nothing: the fact that you've used a pav:previousVersion statement from timetable-002 to timetable-001 already gives one the version sequence one needs. Relying only on one direction may seem counter-intuitive: to know whether something is deprecated, one has to query for whether there is another resource that points to it with pav:previousVersion. But in fact the complexity of the querying is exactly the same, and there are advantages:
- fewer statements in the data
- monotonicity: the statements for timetable-001 don't change
(note that this versioning pattern is the one of the W3C documents!)

Now there's another question about this: whether to use pav:previousVersion or a Dublin Core property, dct:isVersionOf. The definition of pav:previousVersion is semantically more precise, because it links to the version that directly precedes the version being described. while dct:isVersionOf can link to any earlier version. But I expect that in practice dct:isVersionOf will point only to the one previous version. And DC is an official standard, while PAV is not (yet?).


Finally a couple of editorial comments:
- there are many spaces missing in the data, e.g. "dct:publisher:transport-agency-mycity ;"
- I'm missing something in the sentence that finishes with " doesn't exist on the timetable-001.". Like, something that defines what timetable-001 is - as the wording assumes the reader is already familiar with it.

I hope this helps,

Antoine

Received on Friday, 26 February 2016 17:28:38 UTC