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

Thanks for the comments and suggestions Raúl,
> 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.

I think this is the best option. I'll make the appropriate changes.

For the scenario where the URIs do differ, do you have any thoughts on
whether POWDER would be a good approach to making the relationship between
the non-information and information resources explicit?

e.g. <> wdrs:describedby


Steve Battle
Semantic Engineer

Mobile: +44 (0)7503 624 613

Sysemia Limited
The Innovation Centre, Bristol &  Bath Science Park, Dirac Crescent,
Emerson's Green, Bristol BS16 7FR
Registered in England and Wales. Company Number: 7555456

Information contained in this e-mail is intended for the use of the
addressee only, and is confidential and may also be privileged. If you
receive this message in error, please advise us immediately. If you are not
the intended recipient(s), please note that any form of distribution,
copying or use of this communication or the information in it is strictly
prohibited and may be unlawful. Attachments to this e-mail may contain
software viruses which may damage your systems. Sysemia Ltd have taken
reasonable steps to minimise this risk, but we advise that any attachments
are virus checked before they are opened.

> -----Original Message-----
> From: Raúl García Castro []
> Sent: 03 October 2012 09:30
> To:
> Cc:; Steve K Speicher
> Subject: Re: Use-Cases and call for help to add descriptions and
> 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
> 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
> 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
> on any of these use-cases to simply let me know then edit the wiki
> >
> > Some user-stories raise issues which are currently out of scope
> 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
> 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
> was used to create it [BPR]"
> > (5.6.2) and "should remove it from any other containers..." This means
> creating container is distinguished and needs to manage the BPRs is
> 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
> returned representation of the BPR, I think that the example needs some
> clarification explaining that internally the server relates alice.rdf with
> For example, the scenario would be the same if the client makes GET
> HTTP/1.1
> And in this case it should be stated that, for the server, one.rdf
> 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 15:39:41 UTC