Re: Review use case draft

Hi Antoine,

I agree with your assessment and want to ask the group what our plans are 
for continuing to update and improve upon the use cases in the first 
draft.  Do we continue to improve it or just move on to the other work?


Best Regards,

Steve

Motto: "Do First, Think, Do it Again"



From:
Antoine Isaac <aisaac@few.vu.nl>
To:
Public DWBP WG <public-dwbp-wg@w3.org>
Date:
05/30/2014 04:40 AM
Subject:
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.