Scribe
- Martin Sarabura (PTC)
Attendees
- Andrew Berezovskyi (KTH)
- Jim Amsden (IBM)
- Martin Sarabura (PTC)
- David Honey (IBM)
Resolutions
Actions
Chat transcript from room: oslc
[14:07] Martin Sarabura: Martin will scribe
[14:08] Martin Sarabura: https://wiki.oasis-open.org/oslc-core/Meetings/Telecon2018.07.05
[14:08] Martin Sarabura: No feedback, minutes accepted
[14:08] Martin Sarabura: Action items done
[14:09] Martin Sarabura: Query spec
[14:09] David Honey (Persistent/IBM): http://tools.oasis-open.org/version-control/browse/wsvn/oslc-core/trunk/specs/oslc-query.html
[14:10] Martin Sarabura: Abstract missing...
[14:10] Martin Sarabura: Intended to be a kind of elevator pitch
[14:12] Martin Sarabura: Should have an abstract
[14:12] Martin Sarabura: Introduction missing?
[14:13] Martin Sarabura: Abstract should be very brief, introduction is what the document addresses, and motivation indicates why you might be interested
[14:13] Martin Sarabura: Basic concepts text should be relocated to introduction
[14:14] Martin Sarabura: Make sure it indicates what the document covers
[14:14] Martin Sarabura: Basic concepts talked about 2 different patterns
[14:14] Martin Sarabura: used to be more complicated, now simplifieid
[14:14] Martin Sarabura: Terms: Query _expression_, query capability
[14:15] Martin Sarabura: Whatever is helpful to understand meaning of terms, not formal terms
[14:15] Martin Sarabura: Especially if using a word in a particular way
[14:16] Martin Sarabura: Working language for LDP, not even sure they're meeting
[14:17] Martin Sarabura: Jim was hoping that something was going to happen, seems to be not much interest in LDP
[14:17] Martin Sarabura: LDP Patch never got done, nobody working on query language
[14:17] Martin Sarabura: Also seesm to be quite a lot of overlap between LDP and SPARQL 1.0 draft
[14:18] Martin Sarabura: David: They really are quite disjoint
[14:18] Martin Sarabura: Jim: SPARQL graphs provide HTTP interface to SPARQL query, graph is a gettable thing
[14:19] Martin Sarabura: David LDPC is more likely a way of more dynamically determining what the members are, basically a query
[14:19] Martin Sarabura: Jim: From a usage perspective, LDPC are way of organizing and creating resources, whereas graph as a container of triples can play a similar role
[14:20] Martin Sarabura: Jim: Trying to implement LDP in _javascript_
[14:20] Martin Sarabura: David: Motivation provides historical background, explains why original 2.0 spec was difficult for adopters - why not include in motivation section?
[14:21] Martin Sarabura: Where instead?
[14:21] Martin Sarabura: Jim: focus instead on what is in this document that addresses the issues?
[14:21] Martin Sarabura: David: Describes adoption burden, motivation describes how we have lowered the barriers
[14:22] Martin Sarabura: David: If we remove the motivation then why write a new spec?
[14:23] Martin Sarabura: Jim: Focused more on adding spec to core
[14:24] Martin Sarabura: Jim: First bullet move down and focus on what we're doing in this version
[14:26] Martin Sarabura: Martin: Would like to at least indicate why 3.0 is better than 2.0
[14:26] Martin Sarabura: David: Can state this in a positive way that finds the right balance
[14:27] Martin Sarabura: Basic concepts
[14:27] Martin Sarabura: Selective properties already discussed elsewhere
[14:28] Martin Sarabura: Jim: Selective properties kind of looks like a query mechanism
[14:29] Martin Sarabura: Projection mechanism - the relationship between filtering and selecting
[14:29] Martin Sarabura: Useful to point out that we can project via selecting
[14:30] Martin Sarabura: David: Look at sections 10.5 and 10.6
[14:31] Martin Sarabura: Do cover it in more detail further in the body of the document. But people looking for selection will naturally turn to the query spec
[14:32] Martin Sarabura: Discovery: Jim recommends a UML diagram
[14:33] Martin Sarabura: Jim had trouble reading turtle to understand what is it about
[14:34] Martin Sarabura: Diagram could be beneficial
[14:34] Martin Sarabura: David: Potentially 2 useful diagrams, one very generic service referencing query capability - can reuse the one from discovery
[14:35] Martin Sarabura: Not a big diagram, puts everything in context
[14:35] Martin Sarabura: Second diagram is more specific, tied to example 1
[14:36] Martin Sarabura: Example of change requests and defects contain3ed within some container - is this a project with change requests?
[14:36] Martin Sarabura: Picture helps form a mental picture
[14:37] Martin Sarabura: mental model
[14:37] Martin Sarabura: The turtle is pretty complicated
[14:37] Martin Sarabura: Jim: Is it possible that those queries will actually run?
[14:37] Martin Sarabura: David: Would have to try, last tried a while ago
[14:38] Martin Sarabura: Tried to base examples on real RDF
[14:38] Martin Sarabura: Added extra triples as if it were compliant
[14:40] Martin Sarabura: Just like SPARQL result sets, you need to describe result set, didn't see any reason why we needed to introduce variability into how they are described, except for backwards compatibility
[14:41] Martin Sarabura: It's the value shape that tells you the shape of the members of the container, in this case work items
[14:42] Martin Sarabura: For v2 compatilibity, need to describe shape of query as well as shape of values
[14:43] Martin Sarabura: Value shape allows you to discover what you can query on in the query _expression_
[14:43] Martin Sarabura: Gap became apparent only after looking for examples
[14:44] Martin Sarabura: Jim: Try to write down what you just described; withdrawing previous objections
[14:45] Martin Sarabura: Basic container can contain only one thing
[14:46] Martin Sarabura: Section 7
[14:46] Martin Sarabura: Normally don't have normative statements about what a client can do
[14:47] Martin Sarabura: Section 7 is a client concept, not a server concept
[14:47] Martin Sarabura: David: Intent is to be normative, but also want to provide guidance
[14:48] Martin Sarabura: Could change wording to be normative, or could reword in server terms
[14:48] Martin Sarabura: Client simply uses what the server provides
[14:48] Martin Sarabura: David: Trying to provide client guidance
[14:49] Martin Sarabura: Split section 7 into two parts? Normative for server, non-normative for client
[14:50] Martin Sarabura: Sections 8, 9 and 10 could be all subsections of oslc query requiremments
[14:50] Martin Sarabura: Organization is just fine as is
[14:50] Martin Sarabura: Just remove normative clauses out of section 7 and put them into appropriate normative sections elsehwere
[14:51] Martin Sarabura: Jim: Can convert section 7 to "providing a query capability"
[14:52] Martin Sarabura: Then add an introduction paragraph re what server should do, then how client can use it
[14:52] Martin Sarabura: Could create subsections
[14:53] Martin Sarabura: Should use conformance clauses the way ReSpec is now coded to handle
[14:54] Martin Sarabura: Jim: Every conformance clause is a paragraph, therefore you should not put conformance into a bullet list
[14:54] Martin Sarabura: They will come out with the highlighting and tag at the end, linkable, etc
[14:54] Martin Sarabura: David: Will split section 7 into a non-normative guidance for client plus a normative section for server, non-bulletted
[14:55] Martin Sarabura: Jim would pull all the client stuff into the basic concepts section
[14:56] Martin Sarabura: Basic concepts is discovery, usage
[14:57] Martin Sarabura: Not mixing non-normative introductory material into normative sections
[14:57] Martin Sarabura: How to discover, how to run, how to consume results - these are all introductory material aka basic concepts
[14:58] Martin Sarabura: Good point to end, covered up to end of section 7
[14:58] Martin Sarabura: What next?
[14:59] Martin Sarabura: David has some time to proceed with some of this work
[14:59] Martin Sarabura: Next week carry on from section 8 and try to get to end of document
[15:00] Martin Sarabura: Then take all of the feedback and re-rev the document
[15:00] Martin Sarabura: Jim: After one pass he could pick it up with some confidence
[15:01] Martin Sarabura: David: Also remove the red comments inside the document, and close any issues that have been addressed
[15:01] Martin Sarabura: Will need to vote in some cases
[15:03] Martin Sarabura: Jim needs to go through all other specs and mark as conformance clause any instances of MAY/MUST/SHOULD
[15:04] Martin Sarabura: Any such instances inside a non-normative section should either not be capitalized or should be in a different section
[15:06] Martin Sarabura: See section 10.1 - normative section but it has non-normative paragraphs
[15:07] Martin Sarabura: "The examples below show both unencoded and encoded query parameters for clarity" should be moved out of this section
[15:07] Martin Sarabura: The first sentence is clearly non-normative
[15:08] Martin Sarabura: Should be clear what text needs to be removed from the normative clause.
[15:08] Martin Sarabura: Can collect together the non-normative bits
Dr. Martin Sarabura
Technical Fellow, Office of Research & Architecture
+1 (519) 502-4819
msarabura@ptc.com
ptc.comâ