Skip to end of metadata
Go to start of metadata



Coordinator: To be decided


Call will use iSOCO's WebEx, as described in Telecons

Actions from previous meetings

  • Action Rafa/UPM: Put characterising document in Dropbox
  • Action Rafa/UPM: Update content on manifesto table for f2f feedback, see if content fits in deliverable
  • Action Rafa/UPM: Put D3.1 draft in Dropbox
  • Action Marco: validate/update Graham's user reqs
  • Action Marco: Prioritizing user reqs
  • Action all: for next call, make sure we have a draft of current state of docs in wiki/dropbox. If they are in the dropbox, put a note in the wiki: RO related deliverables
  • Action Marco: Make wiki page on upcoming conferences


Agenda Bashing

<Sean>	Hello everybody
<Sean>	Apologies: Oscar, Guillermo, Dave (will be late)
<Sean>	Agenda
        Agenda Bashing
        Review open actions
        Status of deliverables D2.1, D3.1, D4.1
        Any other business

Review open actions

<Sean>	Action Rafa/UPM: Put characterising document in Dropbox: DONE
<Graham Klyne>	Sorry late
<Sean>	Action Rafa/UPM: Update content on manifesto table for f2f feedback, see if content fits in deliverable: DONE
<Sean>	Deleted work objects. States will depend on evolution
<Sean>	Collaborate directly with D2.1
<Sean>	Action Rafa/UPM: Put D3.1 draft in Dropbox: DONE
<Sean>	Action all: for next call, make sure we have a draft of current state of docs in wiki/dropbox. 
        If they are in the dropbox, put a note in the wiki: RO related deliverables: DONE
<Sean>	Action Marco: validate/update Graham's user reqs: ONGOING
<Sean>	Action Marco: Prioritizing user reqs: ONGOING
<Sean>	Action Marco: Make wiki page on upcoming conferences: DONE

Status of deliverables


<Sean>	Status of Deliverables
<Sean>	D2.1
<Stian Soiland-Reyes>	Jun - mute your helicopter! :)
<Rafa(UPM)>	:)
<Stian Soiland-Reyes>	Sean: have worked with Stian (and Khalid) on further identifying the life 
        cycle and how it fits with user roles, but not yet linked it properly to usecases
<Sean>	D2.1-11-05.pdf is a snapshot
<Graham Klyne>	Based on our experience with D4.1, I'm working on some notes that cover linking user 
        requirements with technical aspects, which may or may not be helpful here.
<Stian Soiland-Reyes>	sounds helpful.. will it be in the wiki?
<Graham Klyne>	@Stan - that's the plan.
<Sean>	Rafa: How about snapshot rather than publication
<Khalid> snapshot does not mean that it is accessible or citeable, which is the case of a publication RO
<Sean>	Stian: published vs archived. Archived has a preservation aspect
<Sean>	Marco: focus on defining the things that we want to do in this project
<Sean>	Paolo: Snapshot is something different from publication.
<Stian Soiland-Reyes>	the document we are talking about now is a snapshot of a live object
<Stian Soiland-Reyes>	there might be a new version tomorrow
<Graham Klyne>	There's some work on historic retrieval from the Memento project
<Graham Klyne>	FWIW, I don't think there's a single correct answer to this.  But on case-by-case basis,
         need clarity (e.g. associated metadata indicates fixed or not).
<Sean>	@graham: yes.
<Sean>	I think we need to at least identify what the characteristics of each of these states are, but
         not get too hung up (at the moment) about *how* the identification/versioning process is implemented.
<Stian Soiland-Reyes>	I guess it's important for any reference to include metadata about the target, 
such as a timestamp, perhaps a checksum, content-type, etc
<Graham Klyne>	@sean: yes
<Stian Soiland-Reyes>	Sean: Rather than focus on details such as URIs and versions now, we should 
look at direct requirements
<Khalid>	@sean: I agree, I am struggling to see the difference between publication and snapshot
<Graham Klyne>	Sounds like we want an ontology of objects :)
<Stian Soiland-Reyes>	if we introduce a Snapshot, then what will make it different from a Publication
 (which might not guarantee resolution)? That's the level we should be looking at
<Sean>	Sean: a publication has some expectation of longer life than snapshot.
<Graham Klyne>	Actually, I think what's important is to capture users' expectations (of different 
kinds of RO), then figure out how to deliver them.
<Sean>	@graham: yes.
<Jose>	+1 @graham
<Sean>	@graham: and I *think* we're getting somewhere towards that :-)
<Sean>	at least we're moving in that direction....
<Graham Klyne>	I think this distinction (working vs publication) comes out clearly in the requirements
 we've capturing for D4.1 (from Marco)
<Sean>	Dave: not just one boundary. multiple stages
<Graham Klyne>	@dave yes, multiple stages, but they don't necessarily all surface together in the user
 requirements elicitation
<Sean>	Marco: there are human decisions in every step. These are delibarate steps.
<Sean>	e.g. peer review publication
<Graham Klyne>	q+, to say not so much "continuum", but continuoius process (i.e. ieration, refinement)
<Stian Soiland-Reyes>	Marco: That perhaps what's most important here is 'what is a publication'
<jun>	+1
<Sean>	Marco: critical step is the "publication". Showing stuff to the world.
<Sean>	graham: focus on areas that have greater impact for users.
<Sean>	Paolo: one state with attributes that qualify, e.g. expected updates.
<Graham Klyne>	@paolo: yes, capture user expectations associated with identified kinds of entity/state
<Graham Klyne>	I'm getting a very strong message from Marco that "piblication" is a particularly
 important state to consider (elsewhere Marco mentions "working RO" vs "publication RO")
<Sean>	@graham +1
<Graham Klyne>	I think I hear a core requirement/benefit: "It builds trust"
<Sean>	double edges sword: publication a familar term, but also brings connotations/assumptions.
<Graham Klyne>	Sean: there are connotations associated with the term "publication" -- Marco:  we
 want the effect, maybe negotiate the name;  but model must be abkle to capture this.
<Sean>	Graham: Q for Marco. Requirements work elsewhere distnguishes between working and published.
<Sean>	Make it clear this is not the end of the story, but a start.
<Graham Klyne>	Has the notion of "snapshot" ever arisen in user requirements?
<Sean>	Marco: snapshots belong in working
<Sean>	Marco:maybe hasn't come up in user requirements
<Sean>	Graham: If we're talking about snapshots, is this really a technical feature rather than 
   a user requirement.
<Sean>	Pique: Agree with Marco.
<Jose>	@pique: so, no need for versioning in publication ROs?
<Paolo>	@Jose: I still see versions in publications -- especially for datasets / SW
<Paolo>	I wouldn't like to see that the term  "publication" now anchors our minds on papers/text
<Jose>	definitely!
<Sean>	@paolo: yes. That was my concern about connotation/assumptions
<Graham Klyne>	It seems to me that the notion of publication is in a state of flux; need to
 avoid getting locked into "paradigm trap" based on old models, but focus on goals.
<jun>	@paolo, that's why we really need a clear definition of /publication/
<Graham Klyne>	@sean +1+1+1 don't publish somethign because you want to make a PDF!
<Sean>	I don't publish because I want to produce a PDF. I publish because I want people to know about it.
<Jose>	@sean: yes, the difference lies in the goal of the publication
<Sean>	Paolo: an attribute could be "why am i publishing this".
<Sean>	Another could be scope.
<Sean>	Perhaps call it "distribution", then scope identifies the intended consumers
<Graham Klyne>	Thinking about the word "publication", it seems right to me; i.e. "to make public".
    Maybe the problem is that too many "publications" aren't truly public?
<Sean>	@paolo: +1 for distribution + motivation + consumers
<Jose>	@sean: distribution as release?
<Graham Klyne>	Marco: "publication" is for the whole world.  +1
<Jose>	espistemologically, publication = "make something public", right?
<Sean>	Dave: at what point down the line does something become immutable?
<Sean>	Dave: mutability is an attribute.
<Graham Klyne>	@jose: Ack.
<Graham Klyne>	Marco: first do what we know, then address the nuances
<Sean>	Graham: rough estimate of 5-10 pages.
<Sean>	Graham: focus in D4.1 on information that Marco has provided.
<Khalid>	Although the length is not important, I think that having deliverables that
   have the same/similar length is important
<Sean>	@khalid +1
<Stian Soiland-Reyes>	off for arch telcon
<Jose>	@Graham: I'm not too concerned on the length but I would expect more than 10 pages
<Raul>	I am also off for arch telco
<Raul>	bye
<Graham Klyne>	I'm due to go arch. too
<Sean>	Jose: Can you look at the deliverables in the dropbox and give us some indication of
 whether or not ou think the content/style/approach is appropriate?



Not discussed(question)


Not discussed(question)

Any other business

There will be an extraordinary RO call next Wednesday 2011-05-18 to continue the discussion on the deliverables.

New actions

  • Action Marco: validate/update Graham's user reqs

Next call: 2011-05-18 10:00 BST/11:00 CEST

Coordinator: TBD

  • No labels