RE: Data Cube issues

Dear Dave,

Thanks for this elaborate answer.

I remember that we discussed at [1] the technical detail of the use case
document and how it could help to either raise and solve issues or more
generally motivate QB. However, I think, we did not come to a consensus. 

In discussions with Richard I got the impression that the use case document
rather addresses participants and stakeholders of GLD to make progress on
the spec and less addresses later readers of the spec. This would fit more
to your second type "spotlight on specific detailed technical decisions".
But I also see the reason for your first type "outbound communication of the
specification". In its current status, the use case document contains
application scenarios which should be covered by QB (e.g., Google Data
Explorer) and concrete applications in the wild with their best practices
and challenges of applying QB. As such, it rather is a mixture of both
types. I cannot say which type would fit GLD better.

Best,

Benedikt

[1] <http://www.w3.org/2011/gld/meeting/2012-02-23> 


> -----Original Message-----
> From: Dave Reynolds [mailto:dave.e.reynolds@gmail.com]
> Sent: Thursday, March 22, 2012 10:55 AM
> To: Benedikt Kämpgen
> Cc: Government Linked Data Working Group
> Subject: 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 10:53:38 UTC