← Prev in month ← Prev in thread
Next in thread → Next in month →

OSLC CORE TC Minutes March 2, 2017

From
Sarabura, Martin <>
Date
2017-03-02T18:04:39+00:00
ID
Thread
OSLC CORE TC Minutes March 2, 2017
Scribe

Ian Green (IBM)

Attendees

David Honey (Persistent/IBM)

Harish Krishnaswamy (Software AG)

Ian Green (IBM)

Jad El-khoury (KTH)

Jean-Luc Johnson (Airbus)

Jim Amsden (IBM)

Martin Sarabura (PTC)

Nick Crossley (IBM)

Regrets

Resolutions

Actions

Martin to send out notice to TC prior to next meeting re daylight savings time switch

Nick to review where "rebase" would surface in the spec

Ian to continue the consistency improvements on the draft

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&apos;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

 

Dr. Martin Sarabura

Technical Fellow, Office of the CTO

+1 519.502.4819

← Prev in month ← Prev in thread
Next in thread → Next in month →