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#
Online meeting
(when we need it)
- For IBM employees, use the following link:
- For people outside IBM, use the following link:
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)