Event details


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

  4. Next meeting March 17, 2016
  5. Actions from the previous meeting
    • Jim to update description of oslc:range. Review range values. Email the result for review and further discussion.
    • Jim to email Martin P to see if issue 44 can be closed.

    • Jim to contact Ian Green and Martin Pain re issue 40 to see if there are any changes required from their viewpoint.

    • David: To write proposed resolution to issue 60

  6. Topics
  7. Other business

How to prepare for this meeting

  1. Review the working documents

  2. All members encouraged to review all documents prior to Feb 15!

Voting Rights

Held by:








Chat transcript from room: oslc

2016-03-03 GMT-08:00

[07:06] Martin Sarabura (PTC): Agenda

[07:08] Nick Crossley (IBM): Nick to scribe

[07:08] Nick Crossley (IBM): List of attendees: Jean-Luc Johnson (Airbus), Jim Amsden (IBM), Martin Pain (IBM), Martin Sarabura (PTC), Nick Crossley (IBM), anonymous, ian green

[07:08] Martin Sarabura (PTC):

[07:09] Nick Crossley (IBM): Reviewing minutes of previous meeting - approved

[07:09] Nick Crossley (IBM): Next meeting will be March 17th. May be in Spring Break for some.

[07:10] Martin Sarabura (PTC):

[07:10] Nick Crossley (IBM): Martin: reviewing action items from previous meetings.

[07:10] Nick Crossley (IBM): Martin: issue 40 - does Jim have any update?

[07:10] Nick Crossley (IBM): Jim: let's leave that for the moment.

[07:12] Nick Crossley (IBM): Martin: The next milestone for the TC is to open the specs to public review. Readiness for this needs to be approved by an absolute majority vote - meaning 5 votes in favor.

[07:12] Nick Crossley (IBM): Jim: current state: many are ready for review.

[07:12] Nick Crossley (IBM): Jim: Looking for review of delegated dialogs from Martin P?

[07:12] Nick Crossley (IBM): Martin P: How much change has there been recently?

[07:13] Martin Sarabura (PTC):

[07:14] Nick Crossley (IBM): Jim: Not much. Has had thorough review from Ian.

[07:14] Nick Crossley (IBM): Martin P: Happy with considering it as 'review complete', subject to a resolution to issue 40.

[07:15] Nick Crossley (IBM): Jim: Has made some changes to address that issue - clarifications to language, etc., but no substantive change.

[07:16] Nick Crossley (IBM): Jim: will make sure most recent changes have been posted.

[07:17] Nick Crossley (IBM): Jim: Core vocabulary has been reviewed by several people, including a thorough review by Nick

[07:18] Nick Crossley (IBM): Jim: resource shapes has had extensive review, but may be waiting for review by Martin P?

[07:18] Nick Crossley (IBM): Martin P: will not hold this up.

[07:20] Nick Crossley (IBM): Jim: ReSpec issues with core vocab (common properties) now fixed - thanks to Nick!

[07:20] Jim Amsden (IBM): Proposal 1: Clarify the description of oslc:range to indicate that it is the recommended, not required types. Specifically in the oslc;Property shape for oslc:range, change the dcterms:description from "For object properties, an allowed object resource type." to: "For object properties, specifies what the object resource type is expected to be, but that is not necessarily the case."

[07:23] Nick Crossley (IBM): Nick: why is oslc:range limited to object properties? Could it not also cover literals?

[07:24] Nick Crossley (IBM): Ian: RDF datatype and rdf:type are not the same thing. Agree with the conceptual goal of unifying oslc:range and oslc:valueType, but that would require more thought and work.

[07:24] Nick Crossley (IBM): Nick: Agreed.

[07:24] Nick Crossley (IBM): Ian: use of 'object' in two different meanings in the proposal is slightly awkward. Could we just leave out the second one?

[07:26] Nick Crossley (IBM): Martin P: But the second one is trying to clarify which resource is affected by the property, and the first is using the common phrase 'object property'.

[07:27] Nick Crossley (IBM): Nick: What about 'target resource' for the second one?

[07:27] Nick Crossley (IBM): Martin P: target resource is used elsewhere in the spec

[07:27] Nick Crossley (IBM): Jim: Let's use that.

[07:28] Nick Crossley (IBM): Jim: thinks we should vote on this proposal: For object properties, an allowed object resource type." to: "For object properties, specifies what the target resource type is expected to be, but that is not necessarily the case."

[07:28] Jim Amsden (IBM): +1

[07:29] ian green: +1

[07:29] Martin Sarabura (PTC): +1

[07:29] Jean-Luc Johnson (Airbus): +1

[07:29] Nick Crossley (IBM): Jim:Proposed

[07:29] Nick Crossley (IBM): Martin S: second

[07:29] Nick Crossley (IBM): +1

[07:29] Martin Pain (IBM): I support the change, but am not a voting member

[07:29] Nick Crossley (IBM): Carried

[07:30] Martin Pain (IBM): "The object resource SHOULD be any of the specified oslc:range types, but no inferencing is intended if the actual target resource is or is not one of these types."

[07:30] Martin Pain (IBM): <- oslc:range section

[07:30] Nick Crossley (IBM): Martin P: Following that, do we need to modify the section on olsc:range?

[07:30] Martin Pain (IBM):

[07:31] Nick Crossley (IBM): Jim: thinks the existing language is compatible with the agreed resolution

[07:31] Nick Crossley (IBM): Jim: Next, review the proposed additions of oslc:range to Core shapes

[07:33] Nick Crossley (IBM): Martin P: in the description of the 'type' common property, RDF type should be RDF class.

[07:33] Nick Crossley (IBM): Jim, Ian: Actually rdfs:Class

[07:34] Nick Crossley (IBM): Jim: Is oslc:range included in ReSpec tables? Nick & Jim to check.

[07:34] Nick Crossley (IBM): Jim: Should 'person' properties use foaf:range or dcterms:agent?

[07:35] Nick Crossley (IBM): Nick: dcterms:agent or foaf:agent?

[07:38] Nick Crossley (IBM): Nick: What about compatibility concerns? If we allowed values other than foaf:Person, an OSLC 2 client might fail.

[07:39] Nick Crossley (IBM): Jim: What is the business case for a change? Do we have any scenario where foaf:Person is not adequate?

[07:39] Nick Crossley (IBM): ... silence ...

[07:39] Nick Crossley (IBM): Ian: foaf:Person allows a wide interpretation of Person.

[07:39] Nick Crossley (IBM): Jim: let's leave it as is.

[07:40] Nick Crossley (IBM): Martin S: agent classes seem rather vaguely defined - Person seems as if it might be better

[07:41] Nick Crossley (IBM): Jim: And actions carried out by servers are usually being performed on behalf of some authenticated person.

[07:42] Nick Crossley (IBM): Conclusion is that we'll leave it as foaf:Person

[07:42] Nick Crossley (IBM): Jim: issue 53 - cardinality and structure of service providers & services and their LDPCs

[07:43] Nick Crossley (IBM): Ian: still to review. Nick & Ian to discuss.

[07:44] Nick Crossley (IBM): Jim: Do you intend any spec change as a result of this conversation?

[07:44] Nick Crossley (IBM): Nick: not that I am aware of.

[07:45] Nick Crossley (IBM): Ian: did submit some comments - not sure which ones were applied

[07:45] Nick Crossley (IBM): Jim: did track all received comments, and thinks the document reflect that

[07:46] Nick Crossley (IBM): Conclusion is that we do not think the discussions between Nick & Ian will require substantive spec changes

[07:47] Nick Crossley (IBM): Jim: Issue 44 - cardinality of instanceShape

[07:48] Nick Crossley (IBM): Jim: Is Martin P ok with the language (implicitly) allowing but not specifying a meaning for multiple values?

[07:48] Martin Pain (IBM):

[07:49] Nick Crossley (IBM): Martin P: spec does define meaning of multiple instance shapes ...

[07:50] Nick Crossley (IBM): Martin P: ... in section 6.2

[07:50] Martin Pain (IBM): ... irrespective of the means of associating them

[07:56] Martin Sarabura (PTC): Proposal: Add this to the end of section oslc:occurs Property: "For plain literals with language tags, single-valued means there is only one literal value for any given language tag."

[07:57] Nick Crossley (IBM): Nick: I have concerns about the language in the second to last paragraph of section 6.2 - mixing AND and OR semantics - Nick, Jim, and Ian to discuss offline.

[07:57] Nick Crossley (IBM): Martin S: Issue 60.

[07:57] Nick Crossley (IBM): Jim: Issue 60 has a proposal:

[07:57] Jim Amsden (IBM): Proposal: Add this to the end of section oslc:occurs Property: "For plain literals with language tags, single-valued means there is only one literal value for any given language tag."

[07:59] Nick Crossley (IBM): Nick & Ian: RDF treats untagged strings as different type, so we should separate the description.

[08:00] Nick Crossley (IBM): Ian: this could be a breaking change (but I still think the change is probably the right thing to do).

[08:00] Nick Crossley (IBM): Ian: In early days, we didn;t have people using language tagged literals, so the issue never came up.

[08:02] Martin Sarabura (PTC): We will put this to an electronic vote

[08:03] Martin Sarabura (PTC): Issue 53 still open but not going to hold up public review

[08:03] Martin Sarabura (PTC): Instance shape allowing multiple values: Add clarifying language, though 2nd last para may have an issue

[08:04] Martin Sarabura (PTC): If same language in v2, we'll want to leave as is

[08:04] Martin Sarabura (PTC): E vote for public review

[08:06] Martin Sarabura (PTC): Re issue 60: Already possible to put language tags on literals, nor was there any discussion of cardinality regarding languages

[08:08] Martin Sarabura (PTC): Regardless of decision, it doesn't affect vote on submitting for public review

[08:10] Martin Sarabura (PTC): We need to tag the committee drafts as such when we go to public review

[08:11] Martin Sarabura (PTC): Announcement on

Meetings/Telecon2016.03.03 (last edited 2016-03-04 17:25:31 by sarabura)