Meetings/Telecon2017.03.02

Event details

Agenda

  1. Scribe nomination
  2. Roll Call
  3. Approval of February 16 minutes

  4. Next meeting March 16, 2017

  5. Actions from the previous meeting
    • Jim to send Nick details of ReSpec changes needed.

    • Jim to send note to TC mailing list when the TRS spec is in a reviewable state.
  6. Topics
    • Current status of Core spec review
    • Current status of TRS spec
  7. Other business

Voting Rights

Held by:

Minutes

Chair

Scribe

Attendees

Regrets

Resolutions

Actions

Chat transcript from room: oslc

[07:06] Martin Sarabura (PTC): https://wiki.oasis-open.org/oslc-core/Meetings/Telecon2017.02.16

[07:07] ian green: minutes from previous meeting accepted

[07:07] ian green: next meeting march 16.

[07:08] ian green: actions from previous call. Nick hopes to deal with respec changes within 2 weeks. Jim does not think this is a problem

[07:11] ian green: Jim: quite a few changes needed to terminology.

[07:11] ian green: Martin: current status on core spec?

[07:12] ian green: Jim call for 15 review has been issued; comments might arrive anytime

[07:12] ian green: Then we can commit to specification

[07:13] ian green: Martin - caution about US daylight savings will affect all those in other tzs.

[07:14] ian green: Martin: action to notify to this effect

[07:14] ian green: Jim: Discuss each item in the TRS terminology section

[07:15] ian green: http://open-services.net/wiki/core/TrackedResourceSet-2.0/#Terminology

[07:18] Martin Sarabura (PTC): https://tools.oasis-open.org/version-control/svn/oslc-core/trunk/specs/tracked-resource-set.html#terminology

[07:18] ian green: new terminology: "Tracked Resource" being used in the draft

[07:28] ian green: Jim Gammon: is "state" appropriate?

[07:28] ian green: JimG: suggests "modification" instead

[07:29] ian green: rather than "state change"

[07:30] ian green: Nick: "state change" is used elsewhere; need to be consistent

[07:32] ian green: DavidH: current defn does not mention that TRS needs to be a resource

[07:32] ian green: Nick: "TRS resource" defines the members of the TRS

[07:33] Jim Amsden (IBM): Tracked Resource Set: Describes a resource that defines a set of Tracked Resources expressed as a Base and a Change Log

[07:35] ian green: Martin: should we use "IRI" rather than URI?

[07:36] ian green: Nick: We use URI elsewhere - too late in Core 3.0 for wholesale shift to IRI

[07:36] Jim Amsden (IBM): Tracked Resource Set (TRS) Describes a resource that defines a set of Tracked Resources expressed as a Base and a Change Log Tracked Resource A resource identified by URI that is a member of one or more Tracked Resource Sets. Base The portion of a Tracked Resource Set representation that lists the Tracked Resources Change Log The portion of a Tracked Resource Set representation detailing a series of Change Events on tracked resources Change Event Describes the addition, removal, or state change of a Tracked Resource in a Tracked Resource Set Access Context A grouping of resources with similar security requirements. Access Context List A resource describing a list of Access Contexts. TRS Patch An extended Change Event in a Tracked Resource Set detailing a change to the resources RDF representation. TRS Consumer A Client application that uses TRS resources to discover a set of resources and track changes to them. TRS Provider A Server that provides Tracked Resource Sets.

[07:36] ian green: Nick: we ought to consider IRI in a future version of the specifications

[07:40] ian green: Ian: why "consumer" and "provider" rather than "client" and "server".

[07:41] ian green: Jim: for TRS, these words seem more useful concepts than client/server.

[07:43] Jim Amsden (IBM): TRS Client An application that consumes TRS resources to discover a set of resources and track changes to them. TRS Server An application that provides Tracked Resource Sets.

[07:43] ian green: Nick: we did make decision to use client/server, so for consistency stick with that

[07:46] ian green: Jim: index resource -> tracked resource

[07:46] ian green: Jim: indexable linked data source -> Jim doesn't see need for this term

[07:47] ian green: Jim: nor a "tracked resource data source"

[07:49] ian green: Jim: all resources are "linked data"; "TRS" captures all we need

[07:50] ian green: Jad: "Base" is unclear. Can we clarify

[07:52] ian green: Nick: explains subtleties of relation between base and changelog

[07:56] Jim Amsden (IBM): Base The portion of a Tracked Resource Set representation that lists the Tracked Resources. Change Events in the Change Log are relative to the Base

[07:57] Jim Amsden (IBM): Base The portion of a Tracked Resource Set representation that lists the Tracked Resources at some point in time. Change Events in the Change Log are relative to the Base

[07:57] ian green: Jad: "at some specific point in time"

[07:58] ian green: Martin: should we include "rebase" in this document?

[08:00] ian green: Nick: take an action to review where "rebase" would surface in the spec - but it is an important concept that does need to be covered. Nick will take this action.

[08:01] ian green: Jim: will not have time over the next few weeks. Looking for additional help

[08:02] ian green: Ian: will take action to continue the consistency improvements on the draft.

[08:02] David Honey (Persistent/IBM): https://issues.oasis-open.org/browse/OSLCCORE-85

[08:03] ian green: David: we ought to cover discovery of TRS resources

[08:03] ian green: Closing call

Meetings/Telecon2017.03.02 (last edited 2017-03-02 17:55:53 by sarabura)