Iteration 6 notes
Norman Gray
Folks:
http://code.google.com/p/skua/wiki/Iteration6
Iteration meeting for Iteration 6
2008 September 12, face-to-face, in Glasgow.
Outline agenda:
• What did we get done during Iteration5 ?
• AA.6 Delegated query (Norman) Done (already supported, but tests
and documentation added)
• AA.13 Persistent SAC (Norman) Not done
• AA.10 Add claim to SAC (Kona) Done
• Further myExperiment integration and refactorings. myExperiment
+SKUA now has an interface for adding claims, and is a bugfix away
from that interface being live enough to add them to a given SAC
• Process: comments or responses to Ross's process notes (see skua-
discuss thread This discussion is interesting and valuable, and Norman
will respond to Ross. Broadly, however, we felt that the current oral-
communication model suits us pretty well so far, and is not at present
inappropriate given the small team and the pre-release phase (in
Apache terms, we're probably pre-incubator). We should probably make
stronger efforts to encourage more people to participate in the
skypecons, though.
• Are there missing user stories?
• What would it take for Mark or Noel to find SKUA useful?
• Is that just one or two stories away? Or do we have to think in
more detail about how to get there from here?
• Stories for the next iteration These
• AA.13 Persistence (Norman)
• EC2 deployment (Norman and Tony), and a demo worked out for the
VOTech Cambridge meeting
• Basic RDF validation/parsing in the Java client; extraction of
subject data when subject name specified by user (generic extraction
of data from RDF).
Iteration 6 will be 2008 September 12 – September 24
Notes
Security: yes, it's a good idea, and we'll have to add support for
this in the next few iterations. Stick with the simple model where the
permission to delegate to a SAC determined purely by whether the
delegatee permits the delegator to make the query. At the point when a
SAC is created, the initial metadata will include access controls on
who can alter (or indeed read) the metadata, which will include
changes to access controls.
Updating metadata will be necessary. Should this be the same model as
updating claims (read then replace), or something more abstract?
That's probably sufficient for now, but it might be that a special
interface for adding permission for a specific delegator would be
necessary. On the other hand (Kona) it might be reasonable to demand
that anyone using the 'raw-metal' REST interface can simply be
required to learn a little about RDF.
The plan is still to make a release at end Sept, for VOTech meeting.
Containing: client library, persistent SAC, ??myExperiment deployment
on EC2. Norman: recall how to work EC2, and give Tony access. User-
story: deploy onto EC2. This functionality is the list of user stories
above.
Kona's note: Check outgoing/incoming RDF in client by parsing it
(syntactic validity). Support a basic RDF interpretation method
whereby you can supply a subject name and pull out the matching
information (c.f. extracting http request params etc in http client).
This is domain-independent; might have further layers of domain-
specific clients cf java beans to provide named methods for getting at
particular fields in a particular claim type. Keep basic Java client
domain-agnostic. Need to be reminded of rdf parsing details - use Jena
functionality? There are other RDF parsing libraries - choose a
compact one. Can we add xmlrpc support to the java client? Is that the
right place for it?
--
Norman Gray : http://nxg.me.uk
Dept Physics and Astronomy, University of Leicester
Norman Gray
Ross: I haven't forgotten the process discussion -- I was on holiday
most of this week -- I have a number of responses to your last message
which I'll post here as soon as I get a chance.
Kona: regarding the 'parse RDF' note on the wiki page, would it be
possible to summarise this as a 'user story'? Also, several of the
existing API user stories, and possibly all, are I think implemented,
without ever having been specifically committed to as such in an
iteration. If that's so, would you be able to edit the completed ones
to the bottom of that page. Sorry: I should have brought this up in
the meeting today, but only noticed it when I was editing that page
afterwards. We've been making more progress than we're admitting to!
See you,
Norman
Ross Gardler
> • Process: comments or responses to Ross's process notes (see skua-
> discuss thread This discussion is interesting and valuable, and Norman
> will respond to Ross. Broadly, however, we felt that the current oral-
> communication model suits us pretty well so far, and is not at present
> inappropriate given the small team and the pre-release phase (in
> Apache terms, we're probably pre-incubator). We should probably make
> stronger efforts to encourage more people to participate in the
> skypecons, though.
Thanks for the notes again. I'm pleased you have considered the points
raised. I'm particularly pleased that I see the results of the
consideration and can therefore respect your decision.
So your processes do work in the way you want them to because I, as a
casual observer, am informed :-)
Ross
PS In Apache terms you are most definetely at incubator stage. In fact,
I'd say that if you were in the incubator you'd be about half way
through graduation. The big block at present would be sustainability,
i.e. variety of contributors. Don't underestimate yourselves (or over
estimate the incubator)
Ross Gardler
> • Basic RDF validation/parsing in the Java client; extraction of
> subject data when subject name specified by user (generic extraction
> of data from RDF).
> • Basic RDF validation/parsing in the Java client; extraction of
> subject data when subject name specified by user (generic extraction
> of data from RDF).
Do you have any more details on this point? If you do can you point me
at them please.
The reason I ask is that over at Simal We have a class that does some
validation and parsing. It looks for common errors in people RDF (things
like <foo>http://bar.org/Thingy</foo> instead of <foo
rdf:resource="http://bar.org/Thingy"/>
It also does some useful things like assinging a repository unique URI
to every significant node, tracking original URIs with rdf:seeAlso. This
allows us to do duplicate detection when bringing in RDF from remote
sources (in our case a Project defined at foo may be the same project
defined at bar, when we import foo and bar version we want them to be
the same resource internall).
At present our code is very specific to Simal (DOAP and FOAF) and only
works with RDF/XML (it's a bit of a hack to be honest), but I've been
thinking about looking for a suitable library or, if none exists,
generalising it.
I'd like to explore any potential overlaps in requirements with SKUA,
perhaps we can share resources on this one.
Ross
Kona Andrews
>
> Ross: I haven't forgotten the process discussion -- I was on holiday
> most of this week -- I have a number of responses to your last message
> which I'll post here as soon as I get a chance.
> Kona: regarding the 'parse RDF' note on the wiki page, would it be
> possible to summarise this as a 'user story'? Also, several of the
I have updated the UserStories page, adding stories AA.14 and AA.15.
Ross, what we have in mind for validation right now is extremely
rudimentary: basically just something that checks for syntactically
valid RDF (so for example, a random string of junk supplied as input
could be rejected). Essentially this is a placeholder for more
domain-specific/advanced validation to be supplied later when we have
a better idea of what is required: at that point, I hope we might be
able to re-use some of your functionality.
> existing API user stories, and possibly all, are I think implemented,
> without ever having been specifically committed to as such in an
> iteration. If that's so, would you be able to edit the completed ones
> to the bottom of that page. Sorry: I should have brought this up in
> the meeting today, but only noticed it when I was editing that page
> afterwards. We've been making more progress than we're admitting to!
I have done some updating, and will do some more once today's questions re
updateClaim/getClaim are cleared up.
All the best,
Kona
--
Kona Andrews k...@roe.ac.uk
AstroGrid Project http://www.astrogrid.org
IfA, Royal Observatory, Blackford Hill, Edinburgh EH9 3HJ