This wiki is locked. Future workgroup activity and specification development must take place at
our new wiki
. For more information, see
this blog post about the new governance model
and
this post about changes to the website
.
TWiki
>
Main Web
>
OslcCore
>
OslcCoreMeetings
>
OslcCoreMeeting20110406
(06 Apr 2011,
DaveJohnson
)
(raw view)
---+ OSLC Core Meeting April 6, 2011 [[OslcCoreMeeting20110330][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 %RED%AI: Dave to write up email on email etiquette%ENDCOLOR% 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 %RED%AI: Dave to check on oslc:shortTitle%ENDCOLOR% 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? %RED%AI: Dave to setup meeting for April 13 to continue this discussion (and include Gili) %ENDCOLOR%
E
dit
|
A
ttach
|
P
rint version
|
H
istory
: r2
<
r1
|
B
acklinks
|
V
iew topic
|
Ra
w
edit
|
M
ore topic actions
Topic revision: r2 - 06 Apr 2011 - 15:12:52 -
DaveJohnson
Main
Main Web
Create New Topic
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
Webs
Main
Sandbox
TWiki
Български
Cesky
Dansk
Deutsch
English
Español
Français
Italiano
日本語
Nederlands
Polski
Português
Русский
Svenska
简体中文
簡體中文
Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our
Terms of Use
Ideas, requests, problems regarding this site?
Send feedback