Minutes of OSLC Query work group meeting

[David Honey1 <DavidHoney@uk.ibm.com>]

Andrew Berezovskyi (KTH): Hi Axel
Andrew Berezovskyi (KTH): As far as I understand,
that discussion about cancelling the telco due to the IBM conf actually
became a decision
Axel Reichwein: ah ok

Axel Reichwein: thanks
Axel Reichwein: talk to you later!
David Honey (Persistent/IBM): Andrew, not seeing
you in the Webex telecon.
Martin Sarabura (PTC): Scribe: Martin
Martin Sarabura (PTC): Status of document uncertain
due to reference to obsolete document simple query
Martin Sarabura (PTC): But it does say "where
conflict, this document is correct"
Andrew Berezovskyi (KTH): https://issues.oasis-open.org/issues/?jql=project%20%3D%20OSLCCORE%20AND%20component%20%3D%20Query%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20created%20DESC%2C%20due%20DESC%2C%20priority%20DESC
David Honey (Persistent/IBM): https://issues.oasis-open.org/browse/OSLCCORE-100
Martin Sarabura (PTC): two related issues:
core 100 and 102
David Honey (Persistent/IBM): https://issues.oasis-open.org/browse/OSLCCORE-102
Martin Sarabura (PTC): No examples of actual
returned RDF
Martin Sarabura (PTC): Because you can include
nested properties, you can also return other resources in addition to the
original match
Martin Sarabura (PTC): Simple query syntax
did describe container properties
Martin Sarabura (PTC): rdfs:member could be
used as a container
Martin Sarabura (PTC): RTC tracking and planning
- don't support Query, but do support simple query
Martin Sarabura (PTC): RQM does not provide
any containerr information at all
Martin Sarabura (PTC): GCM application - used
ldp container to contain a reference to each resources found by query
Martin Sarabura (PTC): Any other implementations
of oslc query that we know about?
Martin Sarabura (PTC): And if so, how do they
handle container resources
Martin Sarabura (PTC): Jim: Not going to be
a good answer to this. Examples need to be redone
Martin Sarabura (PTC): Examples should contain
full RDF of results
Martin Sarabura (PTC): Jim: We need to define
what result set looks like
Martin Sarabura (PTC): David: Avoid showing
examples that do not conform to spec
Martin Sarabura (PTC): Can't say that a container
is a MUST - so that existing implementations are still conformant
Martin Sarabura (PTC): Is this OK?
Martin Sarabura (PTC): Since spec doesn't say
anything about containers in the results, one can't make any assumptions
about container given the current spec
Martin Sarabura (PTC): Example: querying for
test cases in RQM. Could assume all RDF resources are test cases where
properties are not nested
Martin Sarabura (PTC): When nested properties
are included, don't know which subset are actually found by the query
Martin Sarabura (PTC): since oslc_select is
optional, what happens when not specified? Results seem to be undefined
Martin Sarabura (PTC): Need a method for discovering
the properties
Martin Sarabura (PTC): Jim: Trying to achieve
2.0 compatibility on an incomplete spec is going to be difficult
Martin Sarabura (PTC): Should we drop compatibility
with 2.0?
Martin Sarabura (PTC): Also, questions in community
whether query satisfies goals
Martin Sarabura (PTC): Seems to be assuming
persistence method is RDF and access via SPARQL
Martin Sarabura (PTC): Bias towards SPARQL
seems irrelevant
Martin Sarabura (PTC): Andrew: If implement
SPARQL then ignore OSLC query
Martin Sarabura (PTC): David: Try to be technology
agnostic rather than assuming underlying query mechanism such as SPARQL
Martin Sarabura (PTC): Wildcards are problematic
- easy for SPARQL since it's graph based, problematic for sql db
Martin Sarabura (PTC): Goal: Reduce burden
of implementing spec particularly for tools that are not RDF based
Martin Sarabura (PTC): David: If we bias towards
SQL then you create problems for SPARQL
Martin Sarabura (PTC): Andrew: Limit expressiveness
of oscl queries to map better onto sql
Martin Sarabura (PTC): David: An implementation
that wants to limit support for oslc query, no way to indicate what is
supported and what is not
Martin Sarabura (PTC): Some sort of discovery
method may be needed
Martin Sarabura (PTC): Jim: Another approach
would be to limit oslc query to minimum set
Martin Sarabura (PTC): David: Problem with
that approach is that some aspects may still be difficult to specify
Martin Sarabura (PTC): Mandatory => may
create burden for implementation eg., full text search
Axel Reichwein: Would GraphQL be relevant in
this dicussion? http://graphql.org/
It is becoming increasingly popular
Martin Sarabura (PTC): Also, existing implementations
that go beyond the spec would not have any guidance
Martin Sarabura (PTC): If we organize spec
into separately implementable chunks then we could define how to discover
support
Martin Sarabura (PTC): for various feature
Martin Sarabura (PTC): Jim: Discovery or not,
you'll still have to deal with error cases
Martin Sarabura (PTC): How many features are
we talking about? Small # of distinct things with specific status codes
on error may be good enough to avoid discovery
Martin Sarabura (PTC): Implementations may
extend the spec to indicate support - oslc is intended to be extensible
Martin Sarabura (PTC): David: A good number
of implementations likely support nested queries so we should include in
the spec
Martin Sarabura (PTC): Whereas other features
such as wildcard not so much, maybe remove
Martin Sarabura (PTC): Andrew: Use 400 (client)
500 (server) error codes should work
Martin Sarabura (PTC): Nested query into some
other resource provider may not work, whereas into same provider could
be supported
Martin Sarabura (PTC): All of the data to execute
the query is contained in same tool
Martin Sarabura (PTC): Cross domain support
likely will result in support for SPARQL
Martin Sarabura (PTC): How do you know whether
nested query will succeed or not in advance?
Martin Sarabura (PTC): No mechanism to discover
this
Martin Sarabura (PTC): David: If predicate
is ambiguous whether resource is external or not then you can't discover.
If predicate clearly indicates that resource is local then you can say
whether query will succeed
Bill Chown (Mentor/Siemens): I had to drop
off, but am very interested in keeping in touch with this one.
Martin Sarabura (PTC): Should be able to report
an error if nested query is going to cross boundary
Martin Sarabura (PTC): Jim: Maybe we need to
be clear on what we want to accomplish?
Martin Sarabura (PTC): Motivation section is
supposed to describe what problems we're trying to solve and the value
of solving it
Martin Sarabura (PTC): And use cases you're
trying to support
Martin Sarabura (PTC): Who remembers what the
original motivation was?
Martin Sarabura (PTC): David: Even just a minimal
implementation is pretty big
Martin Sarabura (PTC): Nick C may be able to
provide historical context
Martin Sarabura (PTC): Maybe Ian G?
David Honey (Persistent/IBM): Query 2.0 spec:
https://open-services.net/bin/view/Main/OSLCCoreSpecQuery
Martin Sarabura (PTC): Andrew: Try to elicit
community opinion on the subject?
Martin Sarabura (PTC): Arthur was the editor
Martin Sarabura (PTC): He's retired but still
reachable
Martin Sarabura (PTC): Jim to talk to Arthur
to find out more about original motivations, how well we achieved them,
and what are his recommendations going forward
David Honey (Persistent/IBM): Original deprecated
spec: https://open-services.net/bin/view/Main/OslcSimpleQuerySemanticsV1
Martin Sarabura (PTC): Dave Johnson and Steve
S listed as authors on v2
Martin Sarabura (PTC): Jim: Arthur shows up
as author on 2.0?!
Martin Sarabura (PTC): v2 does not include
link to old v1 simple queryy spec
Martin Sarabura (PTC): No - under query parameters
Martin Sarabura (PTC): Jim: That's the only
reference to it
Martin Sarabura (PTC): If not specified in
v2, do we inherit from v1? No
Martin Sarabura (PTC): Nothing normative can
be inherited from prior spec
Martin Sarabura (PTC): Result is not defined
here, is it defined in v1 document?
Martin Sarabura (PTC): RDF result with only
the properties specified
Martin Sarabura (PTC): Jim: Need to start over.
Martin Sarabura (PTC): Jim has Arthur's email,
will send asap
Martin Sarabura (PTC): Action item for Jim:
Add to motivation section of document
Martin Sarabura (PTC): Once we have that, we
can go back to intro and terminology sections which are currently missing
Martin Sarabura (PTC): David: Section on graph
patterns is confusing
Martin Sarabura (PTC): Andrew: Is it the same
as SPARQL? Agree section is confusing
Martin Sarabura (PTC): Jim: OSLC properties
intended to establish scope from which query can be executed
Martin Sarabura (PTC): oslc query capability
has various statements you can make incl the query base and reference a
resource shape which might be different from the underlying resource -
a subset
Martin Sarabura (PTC): query base usually a
container, shape indicates what you can access from that container
Martin Sarabura (PTC): oslc select says of
members that came back, what properties of those members do I want to get
Martin Sarabura (PTC): David: Real examples
to validate against implementation will help
Martin Sarabura (PTC): Jim: Move graph patterns
into basic concepts section
Martin Sarabura (PTC): Motivation section can
help us describe what we want to say in this version of the spec
Martin Sarabura (PTC): David: If anyone else
knows of oslc query implementations, provide guidance as to what is supported
and what is not
Martin Sarabura (PTC): Jim: 4 implementations
of query in Lyo
Martin Sarabura (PTC): Andrew: There is a parser,
selection engine is not implemented. Implementations are only the simplest
Martin Sarabura (PTC): Non-nested graph pattern
Martin Sarabura (PTC): Andrew: Not Lyo, some
other implementations
Martin Sarabura (PTC): David: Plagiarized the
ANTLR grammar
Martin Sarabura (PTC): Syntax of oslc query
specific in regards to extraneous white space
Martin Sarabura (PTC): Meeting adjourned
David Honey (Persistent/IBM): Meeting adjourned.
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU