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.

OSLC Core Meeting June 15, 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

(if we need it)

Agenda

Minutes

Attendees and notes from the meeting

Attendees

John Arwe

Frank Budinsky

Jim De Riviers

Steve Speicher

Nick Crossley

Paul McMahan?

Ben Williams

Jim Conallen

Ian Green

Topics discussed

TBD

Action Items

John: Where can I find the motivating scenarios for the TRS spec?

Frank: We've had some along the way in documents and discussions. How should they be added to or linked into the TRS spec itself?

Dave: Most groups keep a separate page of scenarios for each spec that they develop and link to it from the workgroup homepage and the spec itself. Think of the Indexing Proposals as a "sub-workgroup" of the Core spec. You should have a homepage, which could be IndexingProposals, and organize it like a workgroup homepage. Explain the charter, link to the spec, scenarios you issues page and other supporting documents.

Steve: we could add summary of scenarios to the spec itself

Steve: why use dcterms:identifier instead of URI for identification? URI is the Linked Data way to identify things.

Frank: we had long email thread about this topic, talking about blank nodes and whether clients must follow references and ended up where we are now, where we ended up is that each change log item is a blank node.

Steve: Is order now an integer?

Frank: yes.

Ben: Can we add a timestamp in addition to the identifier and the order? There can be multiple Resource Sets and a resource can appear in more than one set, we may need timestamp to be able to merge sets.

Nick and Jim D: agree that timestamp does not help here.

(discussion of resource set merging, multiple resource sets, resources appearing and being deleted from resource sets, overlapping resource sets, etc.)

Nick: from a client point of view, make need to make it clear that clients treat resource sets as if they could overlap.

Ian: if you roll out an RELM and end up with applications that have so much data that they systems are not usable. If there is no way to control volume of data, could that lead to adoption problems? Is it OK to throw triples in the index willy nilly?

Nick: by default, each service provider will have a TRS, e.g. each TRS will correspond to a "module" in DOORs. Admins will have to add each module to the index. Getting off topic here. There are multiple ways to define granularity of Tracked Resource Sets, we need to figure out how to let users configure the granularity.

Jim: we don't need to assume worst case, we do have some control here over how we guide our products into using the right granularity.

Frank: What do people think of the name Tracked Resource Set?

(consensus: name is good)

Frank: what state are we at now in the spec process and how do we move to the next point?

Dave: we are close to convergence, which means we have a "feature complete" spec that we are ready to ask domain workgroups to comment on, and implementation teams to evaluate.

Dave: we should move TRS spec discussions to the Core mailing list, setup an issues page, seek wider feedback from domain workgroups and implementors.

Topic revision: r3 - 15 Jun 2011 - 17:26:18 - DaveJohnson
 
This site is powered by the TWiki collaboration platform 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