Event details


  1. Scribe nomination
  2. Roll Call
  3. Approval of Meetings/Telecon2018.09.06 minutes

  4. Next meeting Meetings/Telecon2018.09.20

  5. Actions from the previous meeting
    • Jim to review the Automation spec, see where it is and why it was abandoned
    • Jim to merge issue 178 into the core spec

  6. Topics
  7. Other business

Voting Rights

Held by:







Chat transcript from room: oslc

[14:08] Martin Sarabura: Please review the minutes from last meeting:
[14:12] Martin Sarabura: Martin to scribe
[14:12] Martin Sarabura: Minutes approved
[14:12] Martin Sarabura: Jim to review the Automation spec, see where it is and why it was abandoned
[14:13] Martin Sarabura: Action item...
[14:13] Jim Amsden:
[14:13] Martin Sarabura: Nick and Jim to look at Automation 2.1 spec
[14:14] Martin Sarabura: Compare with 2.0 spec on which has existing implementations
[14:14] Martin Sarabura: Specs are probably compatible, Nick would like to add one more property
[14:14] Martin Sarabura: Needed by config mgmt spec
[14:15] Martin Sarabura: Actions still under consideration
[14:15] Martin Sarabura: Document in oslc-domains cm: Change Management Actions
[14:16] Martin Sarabura: Working draft, incomplete, not part of the CM multi-document spec
[14:16] Martin Sarabura: New properties introduced in CM 3.0 to bypass actions
[14:17] Martin Sarabura: Not aware of implementations of actions spec
[14:17] Martin Sarabura: Recommendation to leave in draft state unless demand arises
[14:19] Martin Sarabura: Nick: Leaves CM in less than ideal state - servers quite likely to have constraints on states, without a standard to move to IBM RTC will still be based on internal spec rather than OSLC
[14:19] Jim Amsden: ChangeRequest states are likely read-only in most cases and servers provide some other non-standard means of changing the state
[14:19] Martin Sarabura: Long term concerns
[14:20] Martin Sarabura: At least it's stable and insufficient demand to move forward
[14:20] Martin Sarabura: Jim: May be better ways to do it - MQTT?
[14:21] Martin Sarabura: Next action: Jim to merge issue 178 into the core spec
[14:22] Martin Sarabura: Done, conformance classes marked and conformance section added - still need to find conformance clauses in all core specs
[14:23] Martin Sarabura: Needs to be done before we move to standard. Probably doesn't require another review cycle since it's not a substantive change
[14:24] Martin Sarabura: Clarification about missing properties may also qualify as non-substantive
[14:24] Martin Sarabura: Adding properties is probably a substantive change. Jim suggests we assume we will do another review cycle
[14:26] Martin Sarabura: Getting conformance clauses marked: Not so simple... Paragraphs were already marked, have to convert to paragraphs.
[14:27] Martin Sarabura: Nick: The old way was an abuse of HTML
[14:27] Martin Sarabura: Thus there is work involved in switching over
[14:29] Martin Sarabura: Jim has not had time to do it; volunteers to help? Nick doing config mgmt, trs
[14:29] Martin Sarabura: Martin can do at least one
[14:29] Martin Sarabura: David: Can do it for query
[14:30] Martin Sarabura: Attachments already done, core vocab doesn't need to be done - dialogs, discovery, core, resource preview resource shape
[14:30] Martin Sarabura: all those need to be done
[14:31] Martin Sarabura: Jim sent email earlier re which ones use which patterns
[14:33] Martin Sarabura: Martin to do discovery
[14:33] Martin Sarabura: Target before end of this year to go through another review cycle
[14:34] Martin Sarabura: David: Current situation: Edits applied to query, one issue remains: OSLC select vs properties
[14:34] David Honey (Persistent/IBM):
[14:34] Martin Sarabura: Arthur's reply forwarded to TC, slightly confusing
[14:34] David Honey (Persistent/IBM): The semantics of the query parameter are the same as for the query parameter except that its graph matching pattern is applied to each resource in the member list. If this query parameter is not present, then the service SHOULD NOT include any properties (including rdf:type) of the resources in the member list.
[14:35] Martin Sarabura: Do we need to say anything more about
[14:35] Martin Sarabura: Example would be beneficial
[14:37] Martin Sarabura: Arthur's guidance not helping here
[14:37] Martin Sarabura: David: Arthur linked to 2 documents:
[14:37] David Honey (Persistent/IBM):
[14:37] David Honey (Persistent/IBM):
[14:38] Martin Sarabura: Jim: The purpose of properties is to select properties, applied to any resource
[14:38] Martin Sarabura: Only want a subset of properties, use the properties property (ugh)
[14:38] Martin Sarabura: If you have an oslc query with a select clause, happens to use the syntax but otherwise is different
[14:39] Martin Sarabura: David: Applies to different resources
[14:39] Martin Sarabura: David: GET on uri abc, properties applies to that subject abc
[14:40] Martin Sarabura: Query not able to reference property of resource?
[14:40] Martin Sarabura: Example: GET on some URI?param=val1
[14:40] Martin Sarabura: Result is the URI without the query parameter
[14:42] Martin Sarabura: properties has to apply to the subject URL
[14:45] Martin Sarabura: case 1: GET on ok that's easy
[14:46] Martin Sarabura: Applied to a query base, what does that mean?
[14:46] Martin Sarabura: David: Answer should be that it returns all the resources whose rdf types match that of the query base
[14:46] Martin Sarabura: Jim: Definitive statement needed there
[14:47] Martin Sarabura: David: nothing currently in spec.
[14:47] Martin Sarabura: Three use case: GET with neither where nor search terms
[14:47] Martin Sarabura: other is combination of these
[14:48] Martin Sarabura: David: Given we have to reference syntax, we do have a description that briefly describes difference in semantics
[14:49] Martin Sarabura: Nick's use case is valid, not clear how useful?
[14:49] Martin Sarabura: Does relative position of clauses in URI make a difference? David: Should not
[14:50] Martin Sarabura: Arthur described a specific ordering sequence
[14:50] Martin Sarabura: In doc that described transformation to sparql
[14:51] Martin Sarabura: That document describe the steps that you go through in order to execute the query
[14:51] Martin Sarabura: David: Assumes a particular implementation, query spec does not mandate persistence method
[14:53] Martin Sarabura: Is it worth describing example if it doesn't highlight capabilities
[14:53] Martin Sarabura: new capabilities
[14:53] Martin Sarabura: DNG does return info about the query you're running
[14:54] Martin Sarabura: Jim found example of oslc queries in a document
[14:54] Martin Sarabura: David: Oslc primer? Not a standards doc of course
[14:55] Martin Sarabura: Adding to Nick's example: use of useful if query impelemntation returned additional data, and additional data has so voluminous that it interferes with the execution
[14:55] Martin Sarabura: Data could be simply ignored
[14:56] Martin Sarabura: Nick: More realistic example, return resource that reports on statistics; saves the cost of having to do an extra GET
[14:56] Martin Sarabura: Don't know of implementation that does this
[14:57] Martin Sarabura: Jim: Look for examples in the primer, also look at Arthur's semantics of query document and see if he mentions
[14:57] Martin Sarabura: David: Example 1 does
[14:58] Martin Sarabura: Example is not related to query at all... getting project 421 resource which is a resource
[14:58] Martin Sarabura: not a query as such
[14:58] Martin Sarabura: Jim: If find no examples in tutorial, and Arthur's doc doesn't address it, and we assume little value, we can simply avoid discussing it
[15:00] Martin Sarabura: query spec describes how you can use query and properties in same interaction, just no examples
[15:00] Martin Sarabura: David to send email with findings, next week can vote on it - keep it simple vs include an example to flesh out the intent
[15:02] Martin Sarabura: Real examples may be a challenge to get done by next meeting

Meetings/Telecon2018.09.13 (last edited 2018-09-13 16:01:49 by sarabura)