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#

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

Online meeting

(if 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

• Community status
  • Nice round-up of OSLC at IBM's Innovate conferece from Steve Speicher
    • http://stevespeicher.blogspot.com/2011/06/innovate-2011-trip-report-and-oslc.html
• Upcoming Workgroup Schedule
  • June 29 - Baselines
  • July 13 - Core spec retrospective
  • July 27 - Ideas for improving the Core spec
• Continuing the Change Log (link: IndexingProposals) discussion, led by Frank Budinsky

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.