Re: Data Cube issues

Hi Benedickt,

There are two implicit questions here:

(1) Should issues always be related to use cases?

Ans: yes when appropriate, but it is not always appropriate.

(2) For those cases where the answer is yes, should they be captured in 
the UC document?

Ans: no, at least that was my take away from the previous discussion, 
but could reconsider.

To expand ...

(A1) Adding a new feature to the vocabulary should indeed be motivated 
by specific requirements backed up by use cases, no argument there. 
However, if there were a problem such as lack of clarity in the 
specification or an inconsistency or technical error then use cases 
aren't so relevant. Specifically for qb:subslice (ISSUE-34) there is a 
technical problem and a lack of utility. A use case would only be useful 
in that case as a counter argument motivating keeping subslice in. My 
belief/hope is that there isn't a compelling such use case :) Also at 
least part of ISSUE-29 is about clarity of presentation rather than 
specific use cases.

(A2) To me there are two sorts of Use Case documents in spec writing and 
they work best when the two are kept separate.

Firstly, there are Use Cases that motivate the need for the 
specification in the first place and its overall shape. The value of 
this is particularly for outbound communication - it helps people 
understand why we produced the spec and where it might be useful. Use 
Cases for this sort of document should be broadly applicable, relevant 
and motivating to a wide audience, easy to comprehend.

Secondly, there are Use Cases which shine a spotlight on specific 
detailed technical decisions. The value of these is primarily for 
internal decision making. These Use Cases should be as short, narrow and 
as specific as possible to focus just on the one issue at hand. Put too 
many of these in a UC document and it becomes less useful as tool for 
outbound communication.

When you presented the UC document on a telecon I asked about the 
motivation and thought the consensus was more about the first sort - 
helping people understand and use the spec. Though I can't find the 
relevant minutes and may be letting my prejudice colour my memory!

With that in mind, in writing up the ISSUES (which all arise from 
explicit feedback from groups using the vocabulary) I tried to capture 
specific technical use cases where appropriate but didn't feel those 
needed to go in the UC document.

Now specifics ...


On 21/03/12 17:42, Benedikt Kämpgen wrote:
> Dear Dave, all
>
> Thanks for your effort in consolidating the data cube issues [4] and
> mentioning them in the current spec.
>
> I do not want to make the process of raising new issues more difficult, but
> I am wondering whether solving and discussing issues would be easier if they
> would be based on use cases and requirements mentioned in our use case
> document [5]:
>
> * ISSUE-29: Criteria for well-formedness: This issue is required by all use
> cases and specifically mentioned at [1]

Agreed that issue is motivated by all the use cases. I'm not sure my 
text from the issue really works at [1]. Given all the other 
requirements are short I would stop after the first paragraph.

> * ISSUE-30: Declaring relations between cubes is mentioning a use case which
> is also described in the use case document at [2]

I don't think my text for ISSUE-30 works as a Use Case for this style of 
document as is, it was written for internal consumption. If we want to 
have such a use case I could rewrite it.

> * ISSUE-31: Supporting aggregation for other than SKOS hierarchies is not
> covered by any use case. Does that mean we should add a use case, e.g.,
> dealing with geographic information?

That's a case where the ISSUE write up provides two quite specific Use 
Cases. Personally I think that's sufficient motivation. If we want to go 
down the route of a comprehensive motivate-all-features UC document 
then we could add a (rewritten version) of those two but they are at a 
different grain size and I'm not sure that's appropriate for the current 
style of UC document (see A2).

> * ISSUE-32: Relationship to ISO19156 - Observations&  Measurements? is
> covered by use case [3]

Yes.

> * ISSUE-33: Collections of observations and well-formedness of slices
> mentions use cases (bathing water quality use case, air quality use case),
> which are however not included in the use case document.

Actually they are, at least you mention the bathing water quality one in 
UC 4. That mention doesn't go into enough technical detail to motivate 
or clarify ISSUE-33 but that comes back A2 again. I don't think that's 
what this UC document is for.

> * ISSUE-34: Clarify or drop qb:subslice ? Here, no relation to any use case
> is made.

Agreed and not necessary, see earlier comment.


Hope this helps.  If the consensus is that we'd rather go for a more 
comprehensive, motivate every decision, type of UC document then I'd be 
happy to pitch in to help with it.

Cheers,
Dave

>
> Best,
>
> Benedikt
>
>
>> -----Original Message-----
>> From: Dave Reynolds [mailto:dave.e.reynolds@gmail.com]
>> Sent: Friday, February 17, 2012 6:10 PM
>> To: Government Linked Data Working Group
>> Subject: Data Cube issues
>>
>> I've generated a consolidated list of issues for the Data Cube vocabulary
> and,
>> as you will have seen :), registered them on the tracker.
>>
>> These derive from mail list discussions and usage experience over the last
>> year or so, including discussions with Richard prior to joining the
> working
>> group.
>>
>> Note:
>>
>> (1) Just because there is an issue on the tracker does NOT mean we will
>> tackle it during this working group. We may well decide some of these are
>> out of scope or it is premature to address them and so put them in
>> POSTPONED. However, there is still value in recording them.
>>
>> (2) The list is obviously not closed, there may well be other issues that
>> vocabulary users have identified that haven't yet been recorded.
>>
>> (3) If any of the folks on the Data Cube subgroup, most especially
> Richard,
>> would like to clarify any of the issues I've captured then feel free to
> improve
>> the text in the tracker or raise it in email and I'll attempt improvement.
>>
>> Dave
>>
>> [You may see a duplicate of this message sent from the wrong email
> account,
>> if so - apologies]
>>
>
>

Received on Thursday, 22 March 2012 09:55:23 UTC