Review use case draft

Hi everyone,

As requested...
For the record the version I've read is
htmlpreview.github.io/?https://github.com/w3c/dwbp/blob/4c5f96830ed570f440b56b5ad1be20bdf7595f08/usecasesv1.html

First the general feeling:
- It's impressive that Deirdre and Bernadette have assembled such a big doc in a small time
- In many places it shows that they've been rather alone doing this, and not with a lot of time.
In particular there is a lot of heterogeneity in the cases contributed and the analysis of requirements. For a FPWD it may be alright, but I believe there is still a lot of work, and work that cannot be asked to the editors alone (especially with the high number of cases, many of which lacking basic info for further analysis).

I think that to manage expectations there should be a big note upfront saying that this is a first gathering of cases and challenges, and that the group will further distill all this. And that it is also the reason why we put something public for the outside world to comment on.


Second, the requirements that are derived so far are very general: I was hoping that we would get requirements as granular as say, the ones for SKOS:
http://www.w3.org/TR/skos-ucr/#Requirements
This way the work of the vocabularies could have directly followed from the requirements...
I realize now that I was foolish to expect this. The scope of the group (and the cases) is too wide. Rather, what we get from cases now is just a high-level motivation for the vocabularies we want to work on, and some pointers for the editors of the vocabularies to have a look. That is, the vocabulary creators will have to dig into the motivating cases to exploit finer requirements for our vocabularies.
Am I right that this is the level we're happy with? And thus that we'll need more work and time on the vocabulary side?


I have many more specific comments, that I put below. I have tried to focus on these that could be implemented in the limited time Deirdre and Bernadette have.

Best,

Antoine

----

1. Many cases are not real 'cases', let alone 'use cases'. Especially those at the beginning. E.g. case #5 (tracking of data usage), #7 (machine-readability of licenses) and #8 (machine-readability of SLAs) do not have obvious usage scenarios. They look more like general challenges or even requirements. In fact they appear almost as such as requirements later.
There are also cases like #3 and #4 that just call for datasets in specific domains to be published. They don't really say who needs them, for what, nor what the challenges are.
On the other hand, we've got mammoth cases, with real usage scenarios, or at least real data publishers: #21, #25, #21...
Putting them at the end is a bit counter-productive. I would recommend to start with these much more flesh, and then put the smaller or less obvious cases after. Actually in such an editorial state these lesser cases could be just use as a mere excuse to introduce challenges or requirements that are not introduced in the bigger ones.

2. Section "Conformance" can just go away imo: this doc is not a spec. And if a case owner have used, say, 'should' they certainly have not used it with RFC2119 in mind - and I think it's just alright.

3. References to the Open Data principles (e.g. in #5) should have a link to more explanation, e.g. http://opendefinition.org/

4. It would be good to remove bio details, e.g. on #6 or #10. Axel and Carole Post deserve clear, strong attribution for their work. But the way some sentences are written, presenting their life or action, don't read like case-level material.
More anecdotal: Bernadette will certainly claim that Recife's beauty is not a matter of subjectivity anymore, but let's not hint that cases from ugly cities would be less interesting ;-)

5. Could #20 (Radar Parlamentar) be grouped with #12 (Dados.gov.br)? It seems the former is actually a usage case of the latter.

6. The number of requirements for metadata, license, provenance and vocabularies could be lowered: 'open', 'standardized', machine-readable', 'interoperable' and 'documented' are all data publication principles that we could formulate and recommend at a higher level (it is 'meta' level, in fact)

7. The requirement on 'metadata' are not clear. To me license, provenance are also a form of metadata; perhaps even vocabularies: once we have spelled out these more specific levels, it's harder to figure out what remains in the general 'metadata'.

8. Isn't 'interoperable' the mere combination of 'standardized' and 'machine-readable'? (I'm willing to accept it's not, but right now it's unclear to me).

9. I doubt that R-SelectHighValue and R-SelectHighDemand are workable requirements. Who wouldn't need this? Are there really cases that will flourish on crap, irrelevant data?

10. the difference between R-DynamicGeneration and R-AutomaticUpdate is not clear.

11. R-Persistent is not a precise name: wouldn't R-PersistentIdentification be better?

12. R-PersArchiving sounds redundant: the word 'archive' implies persistence. We could just have R-Archiving.

Received on Friday, 30 May 2014 08:40:22 UTC