- Agreement on the three representations of an RO retrieved by content negotiation from RO dereferencing.
- Agreed proposal for M20 system: recognize versioning model (roevo) is not same as underlying system, and target to have a crosswalk from *a* version management system (e.g. git) to the ROEVO model. This will also help crystallise any issues about which resources (URIs) to expose through the API(s).
- Consolidate plenary preparation for architecture topics on the wiki, Architectural discussion points for plenary.
[09:51:13 BST] * kevin.page has changed the chat topic to "Wf4Ever Architecture call 24/05/2012"
[09:52:27 BST] * kevin.page invited drn05r soiland
[09:53:32 BST] kevin.page: 10 minute call :) Please add anyone you think is missing (it was quite a thinly attended call last time but I'm reusing the group)
[09:53:54 BST] * Esteban García Cuesta invited aleixgarrido
[09:53:58 BST] kevin.page: @drn: I've added you following our discussion the other day, should you be around
[09:57:21 BST] gklyne: Hi... just setting up audio...
[09:58:47 BST] David R Newman: me too
[10:00:37 BST] gklyne: I'm ready - is there an agenda?
[10:00:50 BST] gklyne: I think we are talking about APIs?
[10:04:24 BST] gklyne: FWIW, I've been tweaking my SPARQL command line client (https://github.com/gklyne/asqc) to make it play better with REST APIs ... e.g. https://github.com/wf4ever/ro-manager/blob/master/src/roweb/sample-asq.sh
[10:04:25 BST] David De Roure: I'm ready
[10:05:06 BST] Piotr Holubowicz: me too
[10:05:07 BST] gklyne: Me too
[10:05:16 BST] David R Newman: me four
[10:05:27 BST] kevin.page: also for background Graham's wiki page: http://www.wf4ever-project.org/wiki/display/docs/RO+dereferencing
[10:05:40 BST] aleixgarrido: Hi, I'll join you.
[10:06:37 BST] David De Roure: Esteban is in a meeting but says he will catch up with Alex later and read chat
[10:06:46 BST] gklyne: This is the page we used for the SC47 WP4 integration API http://www.wf4ever-project.org/wiki/display/docs/RO+checklist+evaluation+API
[10:07:22 BST] kevin.page: ok, I'll try starting the call
[10:09:14 BST] Piotr Holubowicz: the quality is very bad for me
[10:09:48 BST] kevin.page: Graham recalling with a non legacy skype client :)
[10:11:16 BST] kevin.page: Provisional Agenda
1) Today's topic: RO dereferencing
2) Topic for next call
[10:16:59 BST] gklyne: http://www.wf4ever-project.org/wiki/display/docs/RO+dereferencing
[10:19:58 BST] Piotr Holubowicz: (can you invite Raul again)
[10:20:48 BST] Raul Palma: (please add me)
[10:21:26 BST] Raul Palma: here
[10:22:33 BST] kevin.page: Graham: conclude first three can be representations of RO; 4th not really
[10:26:17 BST] gklyne: Kevin: how do we think of ROs ... content negotiation ... returns "same information". (I agree)
[10:27:09 BST] gklyne: (FWIW, I'd suggest using a 303 redirect for the metadata)
[10:28:02 BST] kevin.page: drn: why only 303 for RDF?
[10:28:36 BST] kevin.page: graham: practical, not principle. for a client to get hold of the URI.
[10:28:56 BST] gklyne: Piotr: suggest also redirect for HTML
[10:31:07 BST] kevin.page: (could you summarise that in chat David?)
[10:31:17 BST] gklyne: It doesnn't sound so unprincipled to me.
[10:31:34 BST] David De Roure: :)
[10:31:46 BST] gklyne: OR: the web page can provide a data link (which is what I think the portal does)
[10:31:56 BST] kevin.page: and myExperiment already had an API to which the linked data interface was added
[10:32:11 BST] gklyne: ^^ I think that's also what Piotr is saying
[10:32:53 BST] gklyne: I think the choiuces we make should not prohibit or require partyicular deployment patterns, like Piotr's separation of portal and data access
[10:33:44 BST] David De Roure: In the back of my mind I have (always) my worry that i call the web-particle duality - that soem users think of an RO as an encapsualted bundle of stuff and others as a description of an aggregation (myExp provides both). One issue is ROs containign ROs (deep zip?). But main issue is permission to get at the peices - where and when does the authentication get dealt with?
[10:34:38 BST] kevin.page: Do we need to distinguish between our notions of RO (at a technical level, for developers using the APIs)
[10:35:05 BST] kevin.page: Graham: think there needs to be distinction as to what is the "same" RO
[10:35:12 BST] gklyne: I think the ROEvo work might help too?
[10:35:19 BST] kevin.page: ...when you download an RO to the client treat it as a different RO
[10:36:05 BST] gklyne: Piotr and I discussed this too... and came to a pragmatic consensus.
[10:37:36 BST] gklyne: ... ask for manifest alone, get manifest for RODL (with absolute URI-refs), ask for contehnt get copy with relative refs in the manifest.
[10:37:51 BST] kevin.page: a versioning schema for the RO URI is new URIs :)
[10:38:04 BST] kevin.page: since we mustn't encode semantics within the URI :)
[10:38:11 BST] gklyne: What is the "same" thing is a deep concept. :)
[10:38:42 BST] kevin.page: do you have a link Raul?
[10:39:11 BST] Raul Palma: not yet in the wiki, it has been on email the discussion so fr
[10:39:13 BST] Raul Palma: far
[10:39:28 BST] Raul Palma: I will add this info to the wiki
[10:39:43 BST] gklyne: This is covered slightly by RFC3986 ... the "resource" may have varying content. See also the W3C TAG archirtecyture example about Weather in Oaxa(sp?)
[10:40:53 BST] gklyne: If you do PUT, then what you PUT MUST be the actual resource representation; use POST to collection where server allocates URI
[10:41:02 BST] kevin.page: +1
[10:41:27 BST] David De Roure: In the distributed object world you have situations where there is consistency guaranteed and other where the guarantees are weak. Following this, the view I took in myExprirment is we could inform people when there is inconsistency but we didn't undertake to fix it - i.e. a weak guarantee.
[10:41:43 BST] gklyne: I agree with version of being resource in its own right. The PROV WG has been here with "Entities" and "specialization", etc.
[10:42:03 BST] David De Roure: The web scaled thanks to getting the right level of weakness
[10:42:29 BST] gklyne: @David, I think this is right.
[10:42:32 BST] kevin.page: +1
[10:44:27 BST] gklyne: REST suggests the representations should have links to other related things you need to find.
[10:45:07 BST] gklyne: KEVIN: VERSIONING AND BRANCHING INTRINSIC TO ROS.
[10:45:21 BST] gklyne: What what does the user consider to be a "new" RO?
[10:45:36 BST] gklyne: See also: http://www.wf4ever-project.org/wiki/download/attachments/2065674/layercake.gif?version=1&modificationDate=1319101294000
[10:46:43 BST] gklyne: Kevin: ... link relationbs...
[10:47:36 BST] gklyne: @Raul - I agree ... it's two issues, but they're related
[10:48:52 BST] gklyne: I think we're moving from the RO dereferencing question to a more general API discussion
[10:49:54 BST] gklyne: Kevin: what about things *within* the RO (thanks! - important point)
[10:51:03 BST] gklyne: q+ to distinguish between new identfiies and replicated content, also more generally about using relative refs
[10:51:36 BST] gklyne: Kevin: how do tools interacxt with the RO EVO / versioning model?
[10:51:59 BST] gklyne: Snapshot and Live ROs are different
[10:52:19 BST] gklyne: (I thimnk that was Raul's comment)
[10:53:35 BST] gklyne: q+ upload ... new RO? I think we answered this
[10:54:35 BST] kevin.page: Graham: VCS optimise storage of versioning beneath the identifiers
[10:54:47 BST] kevin.page: yes, but that implies we're going to use a VCS :)
[10:55:23 BST] kevin.page: Graham: by using relative URI references a new copy must be a new URI/RO
[10:56:15 BST] kevin.page: I was actually asking what happens if you just modify the wf ;)
[10:57:26 BST] gklyne: Kevin: conventions. me: mThis brings us to mapping the "library RO layer" to the "geek implementation layer", does it not?
[10:58:17 BST] gklyne: http://www.wf4ever-project.org/wiki/download/attachments/2065674/layercake.gif?version=1&modificationDate=1319101294000
[10:59:19 BST] gklyne: So, I think the question becomes: What do we choose to present, and how does that map to the "scolarl;y comms and preservation layer"?
[10:59:35 BST] kevin.page: I think it's more that if, say, versioning of wf is delegated to a VCS, that starts putting constraints on the i/face between our services and that (those) VCS
[11:01:24 BST] kevin.page: Violent agreement! :) best try to wrap up then :)
[11:02:28 BST] David De Roure: I have to go onto my 11am SSI call - bye for now!
[11:03:12 BST] kevin.page: Graham: internal mechanisms of versioning not presented at high level; for at least one VCS we have a mapping though (for M20)
[11:03:19 BST] kevin.page: +1
[11:03:49 BST] gklyne: Proposed: for M20 recognbize presented versioning model (ROEVO) is not same as underlying systemn, and targetb to have a crosswalk from *a* version management system (e.g. git) to the ROEVO model
[11:05:40 BST] kevin.page: also shows that using roevo doesn't involve reimplementing a full new VCS
[11:05:48 BST] gklyne: +1
[11:07:01 BST] kevin.page: point of clarity: VCS for resources *within* RO; so the roevo will point to different resources from VCS
[11:09:24 BST] kevin.page: ;) DRN
[11:09:56 BST] gklyne: So, a litmus test might be: can we extract ROEVO information (or implemnet an ROEVO-based API) from a git (or some other) repository?
[11:10:34 BST] kevin.page: but we do need a convention for what our services will implement: when RODL builds the zip representation it needs to retrieve (cache) the right version of the object.... the model makes it sound trivial :)
[11:10:36 BST] gklyne: (Sounds like a showcase to me :) )
[11:11:44 BST] kevin.page: Graham: roevo mediate between tools for versioning and requirements from scholarly comms and pres. layer
[11:12:49 BST] gklyne: I thgink EVO is a valid plenary topic - it does reach across the project layers (mediating...)
[11:14:47 BST] kevin.page: Graham: cover incoming materials for plenary
[11:14:55 BST] Piotr Holubowicz: @Graham +1
[11:16:53 BST] David De Roure: (I'm now in SSI call. Just wanted to say that I;m really pleased about today's discussion, it feels like we're tackling the issues that have been worrying me for a long time. I'm a bit worried that we're not thinking at scale and embedded with other systems, but we have to start somewhere, and as I keep saying I don't want to distract now that we're heading in a forward direction!)
[11:17:32 BST] gklyne: @dave - I would hope that following web arch principles will give us a head start on scaling
[11:18:33 BST] kevin.page: Next meet: review of pre-plenary material; review of ROSR API with Piotr after reflection on today's discussion (flowing into SC47 and API design if time...)
[11:18:40 BST] David De Roure: @graham - yes definitely, that's why we may need to be ok with some consistency weakness, especially as the web is one of the systems we're embedding in anyway
[11:19:33 BST] kevin.page: thanks, bye!
[11:20:10 BST] gklyne: @dave... ah, yes... right now, I'm not sure where that would come into play, but I agree in principle.
[11:20:49 BST] gklyne: ... but "404 is not broken" might be a start?
[11:21:14 BST] David De Roure: yup :)