Re: I think we need Use Cases

Hi!

Karen and I discussed this already and we thought that for the FPWD it 
is sufficient enough to just have the User Stories and requirements.
But I totally agree with you, that we need an abstraction (i.e. Use 
Cases) of those stories.

>  See also [2] on how to possibly implement the Use Cases 1 and 2
> (there are of course other implementations possible).

And that's the point.. We didn't want to give code examples (which we 
thought would be somehow crucial for the understanding of Use Cases), if 
we didn't have reached an agreement on the actual shapes language since 
this might lead to wrong conclusions.
I'm totally fine with adding Use Cases using LDOM, if we agree on that 
at today's F2F meeting though.

cheers,
simon

---
DDipl.-Ing. Simon Steyskal
Institute for Information Business, WU Vienna

www: http://www.steyskal.info/  twitter: @simonsteys

Am 2015-02-17 00:09, schrieb Holger Knublauch:
> I would like to suggest adding a discussion about the topic of Use
> Cases (not User Stories) to the agenda.
> 
>  I believe a lot of the email threads in and outside of the WG are
> mixing up multiple use cases, and therefore we run into unnecessary
> controversies and misunderstandings. In reality we all agree on the
> requirements, but we need to spell out to which Use Case they apply.
> 
>  Here is what I believe what is missing: we have User Stories and jump
> to Requirements from them. However, there are also Use Cases, which
> are generalizations of the User Stories, and which capture the essence
> of those into more abstract entities. As quoted in our current UCR
> document [1]
> 
>  USE CASES [1] are used to capture and model functional requirements.
> Use cases describe the system’s behavior under various conditions.
> 
>  For shapes, such use cases could be:
> 
>  1) Check constraints for a given resource
>      a) against a given Shape (selected externally)
>      b) based on Shapes derived from the resource
> 
>  2) Check constraints for a given graph
>      a) against an externally defined shape selection process
>      b) based on the Shapes derived from the graph itself
> 
>  The distinction between a) and b) is crucial. Both use cases are
> needed. There is another dimension:
> 
>  C) When you are inside of a controlled environment / sub-community
>  O) When you are publishing a vocabulary to the open "Semantic Web"
> 
>  The latter is the "default" intention that is encoded in a vocabulary
> when published, while the former allows anyone to re-purpose data,
> ignoring the default intention. I believe a lot of cross-purpose talk
> in this WG stems from this difference.
> 
>  3) Use a Shape description to build an edit/search form
>      a) with an RDF-based data model / API
>      b) with something like plain JSON (e.g. using JSON-LD)
> 
>  See also [2] on how to possibly implement the Use Cases 1 and 2
> (there are of course other implementations possible).
> 
>  Holger
> 
>  [1] https://w3c.github.io/data-shapes/data-shapes-ucr/ [2]
>  [2] https://www.w3.org/2014/data-shapes/wiki/LDOM_Algorithm [3]
> 
> 
> Links:
> ------
> [1] https://w3c.github.io/data-shapes/data-shapes-ucr/#usecases
> [2] https://w3c.github.io/data-shapes/data-shapes-ucr/
> [3] https://www.w3.org/2014/data-shapes/wiki/LDOM_Algorithm

Received on Tuesday, 17 February 2015 04:49:37 UTC