Re: Use-Cases and call for help to add descriptions and scenarios.

El 02/10/12 22:12, escribió:
> I've completed the first pass through the user stories and the LBP 1.0 document to create an initial set of use-cases - not much more than headings for the most part <>. Each of these now needs to be described in more detail with example concrete scenarios (which may later be developed into test cases). See UC-BPR1 as an example. I've included preliminary issues below for initial comment before adding to the issues list, and invite anyone who wants to chip in with detail on any of these use-cases to simply let me know then edit the wiki directly.
> Some user-stories raise issues which are currently out of scope (versioning, combined POST of binary+RDF) that will not been captured as use-cases unless they are deemed in-scope by the group. The aim is for this document to provide clarification for the current in-scope features.
> More work needs to be done on non-functional requirements to satisfy the latter half of the "Use Cases and Requirements" title, but that's for another day.
> I hope to have the full descriptions and scenarios in place for next Monday, so the more hands the merrier.
> UC-BPR1: Retrieve RDF representation of a resource
> 	• Are non-resolvable non-information resources supported, and are they redirected to BPRs?
> 	• Is Last-Modified returned in the entity header?
> UC-BPR2: Update existing resource
> 	• Should the basic profile recommend at least one patch format, so that we are able to develop concrete examples and test-cases; for example the Talis Changeset <>
> UC-BPR3: Determine if a resource has changed
> 	• Can the Last-Modified date be used in addition to the entity tag?
> UC-BPR4: Delete resource
> UC-BPR5: Create resource
> UC-BPC1: List resources within a container
> 	• The member resources may include non-information resources.
> UC-BPC2: Create resource within a container
> 	• How does the created resource relate to the RDF description? Does the document base have the same referent as the created resource?
> 	• Should POST support a user supplied local-name 'hint', to support more human-readable URIs?
> UC-BPC3: Retrieve non-member properties of a container
> UC-BPC4: Add existing resource or container to a container
> 	• According to the Linked Data Basic Profile 1.0, PUT and PATCH should not be used:- "BPC servers should not allow HTTP PUT to update a BPC’s members" and should only use "HTTP PATCH as the preferred method for updating BPC non-membership properties." See ISSUE-7.
> 	• As BPCs as noted as being potentially large memberships, sending a whole, updated BPC after changes is not practical. See ISSUE-7.
> UC-BPC5: Update container non-membership properties
> UC-BPC6: Determine if a container has changed
> UC-BPC7: Delete a container
> 	• Where BPR's are managed by a container, they may be deleted along with the container. See ISSUE-7, 'The doc talks about the "the BPC that was used to create it [BPR]"
> (5.6.2) and "should remove it from any other containers..." This means the creating container is distinguished and needs to manage the BPRs is creates separately from those it did not.'
> UC-BPC8: Remove a resource from a container without deleting it

Hi Steve,

I have a comment on the example in the Primary Scenario of UC-BPR-1.

While I understand that the URI of the GET can be different of the URI 
in the returned representation of the BPR, I think that the example 
needs some clarification explaining that internally the server relates 
alice.rdf with alice.

For example, the scenario would be the same if the client makes

And in this case it should be stated that, for the server, one.rdf 
corresponds to alice and two.rdf corresponds to bob.

Or, another option, is to use the same URI in the GET and in the 
representation, as in UC-BPC1, and have the case of different URIs as an 
alternative scenario.

Kind regards,


Dr. Raúl García Castro

Ontology Engineering Group
Departamento de Inteligencia Artificial
Universidad Politécnica de Madrid
Campus de Montegancedo, s/n - Boadilla del Monte - 28660 Madrid
Phone: +34 91 336 36 70 - Fax: +34 91 352 48 19

Received on Wednesday, 3 October 2012 08:29:57 UTC