OSLC Core Meeting April 6, 2011

Previous meeting

Link to OSLC Core spec: OslcCoreSpecification

Meeting logistics

How to dial-in to our telecon and login to our screen-sharing session.

Telecon Info

• USA Toll-Free: 888-426-6840
• USA Caller Paid: 215-861-6239
• Participant Code: 6867265#

• Other numbers:
  • https://www.teleconference.att.com/servlet/glbAccess?process=1&accessCode=6867265&accessNumber=2158616239

Online meeting

(when we need it)

• For IBM employees, use the following link:
  • https://lli.ibm.com/meeting/join/?schedid=4446009 (IBM intranet authentication required)
• For people outside IBM, use the following link:
  • https://apps.lotuslive.com/meetings/join?id=4446009

Agenda

Baselines in OSLC discussion led by Nick Crossley

http://open-services.net/bin/view/Main/BaselinesInOslc

Minutes

Attendees and notes from the meeting

Attendees

Dave Johnson

Steve Spiecher

Jim Conallen

Ben Williams

Nick Crossley

Frank Budinsky

Ian Green

Arthur Ryman

Gili Mendel

Topics discussed

OSLC Core baselines proposal

Dave: welcome to the Baselines discussion by Nick. We will use online meeting to review Nick's proposal and Steve's comments, which are attached to the proposal.

Dave: do we have other items for today?

Steve: one item - we need to give some guidance on email etiquette to the mailing list, people are not following mailing list best practices

AI: Dave to write up email on email etiquette

Ben: is baselines the right term, it means something special in RM

Nick: would like to stick with baselines

(next, we start walking through Steve's comments)

Nick: re: Steve's change-set comment, not a priority issue because not all systems support baselines.

Steve: in some systems, a change set is not complete until it is declared to be so

Frank: when you do a snapshot, things that are related to a resource may not be part of the snapshot created? We'll touch on this issue later in the review

Nick: re: Steve's comment about incremental baselines. Nick, tend to agree, we don't need to support creating baselines from baselines

Frank: the need arises when you need to compose baselines, I was thrown off by your use of composite baselines in another sense

Nick: composite baseline contains resources from more than one tool or provider, perhaps we do not need this term, any baseline can be "composite"

Nick: re: Steve's comment about dcterms:name, agree that oslc:shortTitle works, but it is not in the OSLC Core Common properties

AI: Dave to check on oslc:shortTitle

Steve: with isSnapshot, does this mean that all members and transitive members are also read only?

Nick: yes, that is what you would expect

Ben: what happens when you want to baseline a collection of requirements, but not all members of that collection?

Nick: but you do want to have all those members in the baseline, what is done in some products is not sufficient.

Nick: baseline does not need to include directly all resources that are transitively included in the baseline

Ian: if you have a requirement collection that is part of a snapshot, and you do a get on that snapshot you get a link to that requirement collection, but not all of its contents

Nick: re: Steve's comment about violation of GET, yes this is a problem. We should use the alternative snapshot method, further down the page. Better approach is the "camera service" which is my preferred approach now. Still some question about what return value should be, especially when you have to handle multiple resources in a POST. We can refine the shape of the request and response as we go along.

Frank: how would one know which camera service to use?

Nick: makes sense to have one camera service per Service Provider. Could be at Service level, symmetric with other things, but I prefer Service Provider level

Nick: snapshot capability is useful in its own right, but it is optional -- providers could use other methods to form snapshot

Arthur: snapshot is verbatim copy of resource, or does it contain additional metadata

Nick: not currently defined, except for existence of isSnapshot property

Nick: perhaps there could be a non-versioning provider, that just freezes the resource itself instead

Arthur: might be better to have separate resource for each snapshotted resource, so "metadata" can be kept separate

Arthur: does this only include RDF resources?

Nick: no, we need to be able to handle any type of resource

Nick: when you do a get on a snapshotted resource, you get the same information back, for ever, it never changes

Ian: how does this interact with security, a request with different permissions may get different information that one with other permissions.

Nick: that may be a per-provider issue. Each provider's camera has to take care of that.

Jim: How does a client know that any given set of URIs that some of them are actually identical but different snapshots, how do you know that one URI is the same as another, like OWL same-as

Arthur: no, not that (i.e. OWL same-as)

Nick: that has to be provider specific, what that means could be different for different providers. e.g. SCM, already offers multiple version of resources, so we have an ID property in the resources

Jim: so the dcterms:id would be the same across those "same" resources

Nick: right, that's how it works in SCM, but we don't want to dictate that across domains

Arthur: we should standardize this, there should be some vocabulary to indicate "same as"

Nick: that does not always make sense, is it the same resource or multiple copies of it?

Jim: if I have a list of books to read, I want to know if there are copies. Don't want to find out via deja vu

Arthur: this is a common problem in RDF, should be able to describe this via property values.

Nick: I think these are things outside the scope of baselining proposal, I'd prefer to have that debate on a more broad-level and not limit discussion just to snapshots. Perhaps we need an OSLC wide way to indicate "same as" for resources.

Dave: time check, we have five minutes

Nick: let's sum up where we are:

- want to change GET to post, use camera service instead

- we have an ongoing discussion on semantics of what is a snapshot, keep track of transitive deps, does it provide a same-as capability.

- currently, this proposal requires rewrites of links. Do all links have to be rewritten, transitively?

AI: Dave to setup meeting for April 13 to continue this discussion (and include Gili)