RE: Use Case document

Hi - belated response :-)

My recollection from the F2F is that we wanted to add a section to the UCR doc that summarised the use cases; e.g. in order to help users with new use cases determine if their use case was already covered.

In my mind, I thought that a table providing 'one-liner' (or at least very concise) summary and a cross reference to the related requirements* for each use case would be sufficient.

I can't progress this at the moment due to commitments on the mapping docs ... 

Eric - could you make a 'prototype' of this (or whatever you think is most appropriate) for, say, the first four or five use cases? Then we can assess the utility & determine if we want to complete the set & add it to the UCR doc. Please advise if you are already maxed-out with work; if so we'll just leave this as pending (although we ought to add an issue relating to this in the github so we don't forget!).

Many thanks, Jeremy

* we may want to use the requirements groups (from the section headings in the UCR document) to provide an even more high-level overview - but I am not sure if these section headings are adequate.

-----Original Message-----
From: Ivan Herman [mailto:ivan@w3.org] 
Sent: 10 November 2014 07:56
To: Eric Stephan
Cc: Tandy, Jeremy; W3C CSV on the Web Working Group
Subject: Re: Use Case document


> On 08 Nov 2014, at 19:41 , Eric Stephan <ericphb@gmail.com> wrote:
> 
> Ivan,
> 
> The original question was posed by Eric P (RDF Data Shapes Working Group) the first morning, I'm not sure if he had seen the use case document.   It seemed to be related to the situation where an external reader who has a background in another domain could relate to use cases already identified in our document.
> 
> In order to orient themselves, would they need to read the entire document?  Should they start with the requirements?  Or perhaps another approach that could be used such as a reference table summarizing the CSV usage in each scenario as a capabilities need.  

So, maybe, what we can do is something a bit less formal than what I wrote. Instead of making formal references, we can add a note to each requirements on whether this Working Group will 'answer' that requirement in what it produces (with some references to specs or overall design elements) or whether it decided that this would go beyond the charter or what the WG can achieve in this round and that it is postponed to a successor group if the community decides to set up one.

How does that sound? I think it would probably be very useful for all of us, too.

Thanks

Ivan

> 
> Cheers,
> 
> Eric
> 
> 
> 
> On Thu, Nov 6, 2014 at 11:56 PM, Ivan Herman <ivan@w3.org> wrote:
> I am not 100% sure what this would mean and how. Should we have a pointer from each requirements to issues and resolutions in the WG? I do not think we have such a systematic set of issues or resolutions... But maybe I do not understand what the idea was.
> 
> Ivan
> 
> 
> 
> > On 06 Nov 2014, at 18:32 , Eric Stephan <ericphb@gmail.com> wrote:
> >
> > Jeremy and all,
> >
> > As I recall from our F2F meeting [1]  we discussed the use case document was in a fairly complete form.  We did discuss on the morning (see below) of the first day the possibility of including a look up table to help orient users with new use cases in mind to see if there requirements had already been captured.  Is this something we want to pursue?
> >
> > Eric S
> >
> > References
> > [1]  http://www.w3.org/2014/10/27-csvw-minutes.html

> >
> > ericp: A measure of success may be that someone can bring in a use case, look at the requirements and see if theirs are included already
> > phila: The use case document for CSVW is useful for DWBP. That group (laufer) will pull use cases from this group's document for that group's use case doc.
> > laufer: You are talking about a file with metadata for other CSV files, and I've seen that you've proposed a file extension. We will have other metadata files, but I'm not sure a particular extension would be useful. A general way to link metadata files to data files may be better.
> > jeniT: we'll be discussing that later today. But it contains 4 mechanisms for finding metadata; appending a file suffix is one of the four.
> > ivan: Looking at the Use Cases document, to the editors: is the document done?
> > jtandy: I think we have a good collection of use cases. There may be others to include. D3: data driven documents — we may want to look at it.
> > ... As we reviewed use cases earlier this year, we saw that most requirements in them had already been covered. But the requirements do need more work. They are placeholders that allow us in the group to work on them.
> > ericstephan: I'm not sure if we've drawn out — if we found use cases that correlated well, we combined them. That was an internal, organic process.
> > ... It might be useful to show something like characteristics? Not a requirement.
> > jenit: can you give an example?
> > ericstephan: In science efforts, there may be an approach (imaging formats, for instance) used in an entirely different discipline.
> > ... Is it enough to put it in requirements, or is there another outreach mechanism that would help draw people in, so they can relate to a use case?
> > jtandy: As an example, we had to work out which use cases covered data transformation. Not a requirement, but something they have in common. Maybe a simple lookup table at the topic?
> > danbri: Do you have everything you need to do that?
> > jtandy: the ones we have are sufficiently articulated to do that. We should give them the chance to comment though.
> > danbri: and in terms of having their actual CSV files?
> > jtandy: Sometimes. Some are behind corporate firewalls. Obviously only those use cases that talk about transformation can have target XML, RDF, JSON. But examples of those help.
> > ericstephan: It's like saying, "Here's something that illustrates this use case, and here are some sister or related datasets from something similar."
> > ... So you could expand from datasets from the explicit use case.
> > jtandy: But given the limited resources of the group, we have to balance that idea along with meeting the other deliverables. Let's try to work that out this week.
> 
> 
> ----
> Ivan Herman, W3C
> Digital Publishing Activity Lead
> Home: http://www.w3.org/People/Ivan/

> mobile: +31-641044153
> ORCID ID: http://orcid.org/0000-0003-0782-2704

> 
> 
> 
> 
> 


----
Ivan Herman, W3C 
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/

mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704

Received on Tuesday, 18 November 2014 10:03:14 UTC