User stories have moved

I've moved the user stories to the project issues list. Add new stories there, tagged with Type-Userstory, which will happen automatically if you use the 'user story' template. Some of the stories below are already completed, some have been rendered moot, the remainder should be gradually migrated to the issues list.

Potential future stories

There are some stories implicit in WhatSpacebookWants, though these are right now expressed as a sketch API.

User: application author

This is someone most concerned with the SKUA Interfaces

HTTP interface

There is already an interface implemented for Quaestor, which is acting as a SAC in the initial stages. The qsac implementation which Norman released builds on Quaestor to provide a SAC-specific variant of this interface (qsac documentation and tutorial are at http://myskua.org/doc/qsac).

AA.3 Application makes a query which is enhanced by astronomy-specific semantic information. This might be as simple as making sure that a SAC 'knows' that BlackHole IsA CompactObject

AA.4 User uploads personal "knowledgebase" of triples which is then used, via reasoning, to inform their subsequent uploads of data. (Should the reasoner be implemented in the SAC, to produce extra triples that are then stored in the triple-store? This should be the most platform-independent way of doing it...)

AA.5 Update RDF Elaboration required: We have a number of possible ways of doing this. Options include implementing the Talis changeset protocol, the SPARQL/Update Jena extension, or something crude involving getting a current bag/subgraph, changing it locally, and pushing the replacement. This is in some sense supported already, because clients can change claim RDF by simply rewriting it -- this story is a more sophisticated alternative, involving edits to claim RDF, which may not be necessary

AA.16 Authentication This is a large bag of stories, which needs significant elaboration. Who is to be authenticated? What has to be authorised? Do we use certificates, proxies, HTTP digest? Perhaps use Astrogrid Security Facade

AA.17 Reconfigure SAC via API An application lets the user adjust permissions/delegation ia an application-specific UI, which is then reflected in the SAC via some RESTful call.

Java API

The stories in this section are to do with API wrapping around the RESTful interface described above

AA.8 Application author prepares and submits a SPARQL query to a SAC. Uses an API function which performs the actual RESTful interaction. Requires design and implementation of that API function, and library infrastructure. Language?

AA.9 Application submits a SPARQL query to a SAC which delegates it. Elaboration required: Should this look in any way different to the previous one? Do we need to be able to say do/don't delegate this? Dependent on the delegate query story in the previous section.

AA.11 Delete/replace claim. Yes, two stories in one line... Elaboration required: we could/should demand that claims are always added to a specific bag.

AA.12 Add/delete/replace a collection (bag?) of claims. Ditto

AA.14 Basic RDF validation/parsing in the Java client. At this stage, only very rudimentary syntactic validation will be applied (no semantic/domain-specific analysis until our requirements are more clear). Basically just a sanitycheck that the supplied RDF is syntactically valid.

AA.15 Basic extraction of subject data when subject name specified by user (generic extraction of data from RDF). This will be rudimentary/domain agnostic to start off with; nothing fancy. We can flesh it out later.

User: 'astronomer'

Higher-level stories, which possibly need to be broken down into a UI and an API aspect of the story, inasmuch as the users will interact with a slim management application which in turn uses the APIs above. Or not...

AU.1 User starts/creates a local SAC. We anticipate that a (local) SAC is something that a user might start up for themself. Elaboration required: do we anticipate that this will be a long-running thing, or might a user start up a SAC temporarily, do some work with it, and then chuck it away? We suppose this is a jar file (wrapped as a .app on OS X). But what does it look like? Perhaps it would be nice if there's some sort of basic feedback in the UI, just to give the user something to look at. A log file? A rolling count of the number of claims or triples in the SAC? Some UI to set up delegation or access control? Is this the same application as the general client app -- that is, is the putative SAC-managing client app also itself a SAC?

AU.2 User creates a SAC in a 'Multi SAC'. A Multi SAC is a SAC service which contains multiple SACs, each of which has the same function as a local, standalone, SAC. Thus this is essentially a registration story.

AU 3 User changes SAC metadata. Such metadata includes things like the owner (should that be changeable?), title, and so on. Elaboration required: do we actually need this? If a SAC has only default, fixed, metadata, that's another thing that doesn't have to be elaborated, documented, and have the user aware of.

AU.4 User declares that another SAC can delegate to this one.

AU.5 User pushes one or more claims to another SAC. Elaboration required: do we say that SAC A can delegate to SAC B iff SAC A is allowed to push claims/bags to SAC B (in which case we don't have to have two distinct permissions -- the permission is just 'will help' (what's a word meaning 'is pals with' which is asymmetric without sounding unfair))?

AU.6, AU.7 ...and the same two with access control. Messy, probably.

AU.8 User enters a SPARQL query into a UI (oooh, funky user). Requires: the existence of library support. This is a UI story, distinct from the application author submits SPARQL query API story above.

AU.9 User adds/removes/lists SAC user(s). Multiple stories. Elaboration required: who are the 'users' of a SAC? Is it just the list of people who can reconfigure it?

AU.10 User adds/removes/lists bags in SAC.

AU.11 User clears the contents of a SAC

AU.12 User obtains logging/history information about a SAC

Complete applications

These are applications using the SKUA infrastructure

Spacebook

see Spacebook

Suggestions server

???

Catalogue Annotations

see CatalogueAnnotations

Completed stories

User: application author

Create SAC. Done, if Quaeator counts as a SAC for this purpose.

Add RDF. Done, by adding RDF to a Quaestor submodel

Query SAC. SPARQL queries of a Quaestor knowledgebase

Get a basic servlet running Effort 1 day. Norman, 3 days, in Iteration2

Application adds a number of triples to the SAC, either PUTting to a named claim, or PUTting to its parent and getting a named claim in the response. Effort: 2 days. Norman, about 3 days, in Iteration2

get servlet unit tests going. Effort: 2 days, but if a SAC appears from Norman, that might be usable instead. Done by Kona, ??days, in Iteration2

Application adds a single claim to the SAC. Elaboration required: should this be different from 'add triples to a SAC'; that is, does a SAC have to know about Claims, or can it just concern itself with the triples alone? For elaboration, see notes on Interfaces. This might be done already, since Norman's qsac implementation allows you to add any RDF, but in a context which has a new claim URI as its base URI. Does more have to be done here? Probably not. So count this as done, without really being formally committed to, Norman, Iteration2

AA.1 For app author. User works through tutorial, or other introductory docs. Norman's qsac has reference documentation, but it's fairly concise, and you have to know it's there. Effort: 1 day. Iteration3

AA.2 For app author. Download and install iteration release. Ie, create the infrastructure for an iteration release. Norman will do this, in the sense of creating the top-level push-button for 'create a release', and will stock it with the qsac server. Related stories (tbd) concern putting other components (end-user client and spacebook mods) into the same release infrastructure. Done in Iteration3 (not quite a push-button, but there's a `dist` target in the top-level Makefile in the repository, and aiming-to-be-helpful notes in the `README`.

S.1 Tony/Spacebook: Call addClaim RESTful API call. Effort: 3 days Iteration1, Iteration2, done Iteration3

AA.6 Delegated query Application makes a query against one SAC, which is then automatically delegated to others. This may be effectively done in qsac, since Quaestor can do this. Therefore this story is more about adding the documentation and unit tests for this (Norman). Done in Iteration5

AA.10 Add claim to SAC ...as a Java call, using the RESTful API (Kona). Done in Iteration5

AA.7 Java API: Implement addClaim method to call RESTful addClaim method Effort: 2 days. Done in Iteration5; this is a duplicate of AA.10.

AA.13 Persistent SAC API-user creates a SAC and configures it to persist. Shuts down the SAC, restarts it, and sees the same data present. Persistence is controlled by the metadata which is PUT to the multiSAC to create the SAC, and further controlled by server-side configuration. Should the Java API provide methods to make this simpler? (rather than requiring the user to set up the required RDF metadata?) – possibly. Iteration6