Re: [oslc-core] OSLC query, vote on query results container MUST be an LDPC

["Jim Amsden" <jamsden@us.ibm.com>]

Perhaps if there's any doubt re: MUST or
SHOULD, maybe we should us SHOULD?


Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575




From:      
 "Nicholas Crossley"
<nick_crossley@us.ibm.com>
To:      
 oslc-core@lists.oasis-open.org
Date:      
 10/05/2018 09:39 PM
Subject:    
   Re: [oslc-core]
OSLC query, vote on query results container MUST be an LDPC
Sent by:    
   <oslc-core@lists.oasis-open.org>

---

I recall the earlier discussions now.
My thinking at the time was that, yes, this would make OSLC 3 incompatible
with OSLC 2, in that existing OSLC 2 servers would be incompatible. However,
a server that wanted to be compatible with OSLC 3, and that did not already
provide a query base that was an LDPC could convert its existing query
base to be an LDPC by adding the necessary link headers and properties,
including an ldp:hasMemberRelationpredicate
defining the existing query result relationship.

Since the additional link headers and properties could be ignored by clients,
this change would be upwards compatible.

The advantage to going in this direction with the spec is that future clients
could then rely on there being an ldp:hasMemberRelationpredicate
to find the results; with OSLC 2 query, clients have to know or guess at
the result predicate, since it is not well defined, and does vary between
existing servers.  This existing variance is also why I do not believe
we can do as Jim suggests and reduce the spec to requiring one fixed predicate
such as rdfs:member.

That existing variance is a significant problem in writing generic OSLC
query clients today, so I think the decision as to whether the spec says
the result MUST or SHOULD be an LDPC is a tradeoff between the benefit
in reducing this lack of precision in the 2.0 spec vs. the cost of making
a server OSLC 3.0 compliant. Since there is no rush to make such OSLC 3.0
compliant servers, and since the change is upwards compatible, I now tend
to lean to my original vote in the minutes found by David, and withdraw
my suggestion of weakening it to a SHOULD. However, since a SHOULD clause
does provide guidance to any future implementations, I do not feel this
is critical, and I'd accept either SHOULD or MUST. I do think the spec
should call out use of an LDPC here, as that is the obvious way to avoid
perpetuating the problem of an undefined result predicate, and as David
mentioned, we have other existing uses of the Linked Data Platform in TRS
and Configuration Management, so the 3.0 specs do rely on LDP and LDPCs
anyway.

Nick.



From:        David
Honey1 <DavidHoney@uk.ibm.com>
To:        "OSLC
Core TC (oslc-core@lists.oasis-open.org)" <oslc-core@lists.oasis-open.org>
Cc:        Nicholas
Crossley <nick_crossley@us.ibm.com>
Date:        10/04/2018
03:27 AM
Subject:        [oslc-core]
OSLC query, vote on query results container MUST be an LDPC
Sent by:        <oslc-core@lists.oasis-open.org>

---

Following up an action from last week's meeting, I found the meeting minutes
where we discussed whether the requirement for a query results container
to be an LDPC was voted to be a MUST rather than a SHOULD: https://wiki.oasis-open.org/oslc-core/Meetings/Telecon2018.07.19

Here an excerpt from the minutes|: 
14:22] Andrew Berezovskyi (KTH): Jim: why care about LDPC adoption in case
of the Query (only)?
[14:23] Andrew Berezovskyi (KTH): RQM is one of the tools using a custom
predicate
[14:24] Andrew Berezovskyi (KTH): ^(NIck)
[14:26] Andrew Berezovskyi (KTH): one option is that we make LDPC method
a must, the oslc predicate can be a MAY; Martin thinks it would be good
to have a "clean" implementation example. Jim: in reality most
clients & servers would have to implement all options.
[14:27] Andrew Berezovskyi (KTH): Jim: we can adopt LDP as the memb pred
specification mechanism, then express the default rdfs:member and oslc
predicate as membership predicate and an equiv predicate membership declaration
method respectively
[14:29] Andrew Berezovskyi (KTH): David: if nothing is provided, rdfs:member
MUST be used. If a shape is given, a given predicate MUST be used. If we
make LDPC a must, all v2.0 implementation will not be compliant with v3.0.
[14:30] Andrew Berezovskyi (KTH): Nick: that would not be the end of the
world. we want compat for clients, not necessarily for the servers!
[14:31] Andrew Berezovskyi (KTH): David: the 2.0 spec was vague on some
statements and just by clarifying them in 3.0, many servers may be incompatible
with the 2.0 clients
[14:34] Andrew Berezovskyi (KTH): David: LDPC still can be a MUST and the
clients will still be able to consume the results via shapes
[14:34] Andrew Berezovskyi (KTH): David: this will make the section simpler
[14:34] Andrew Berezovskyi (KTH): Jim: I don't see the much demand for
LDPC in this context.
[14:35] Andrew Berezovskyi (KTH): David: I don't think SHOULD will be of
any help to promote the use of LDPCs.
[14:37] Andrew Berezovskyi (KTH): Jim: MUST has risk of forcing some constraints
that have no value prop
[14:39] Andrew Berezovskyi (KTH): OPC-UA
[14:41] Andrew Berezovskyi (KTH): strong points: strong specs of profiles
and certification
[14:42] Andrew Berezovskyi (KTH): downside: 1200 pages+ in the ISO standards
[14:42] Andrew Berezovskyi (KTH): Jim: OSLC has a different philosophy
[14:43] David Honey (Persistent/IBM): https://www.w3.org/TR/ldp/#ldpbc
[14:44] Andrew Berezovskyi (KTH): Jim: is the LDPC MUST and no explicit
membership predicate are incompatible
[14:44] Andrew Berezovskyi (KTH): Nick: again, that will make existing
2.0 servers non-3.0 compliant
[14:45] Andrew Berezovskyi (KTH): Jim: it will inhibit integration
[14:45] Andrew Berezovskyi (KTH): David: it would be just a few more triples
[14:45] Andrew Berezovskyi (KTH): Jim: products will be slow adopting this
[14:47] Andrew Berezovskyi (KTH): Andrew: I believe we should consider
OSLC version header, as HTTP, TLS and others do
[14:50] Andrew Berezovskyi (KTH): Nick: versioning would allow gradual
improvement. Jim: we need to encourage compatibility and have clients discover
new capabilities.
[14:50] Andrew Berezovskyi (KTH): Andrew: what if we do two different capabilities
and support discovery
[14:51] Andrew Berezovskyi (KTH): Nick: but that would place a lot of burden
on the impl: new predicate, new endpoint etc. + old clients won't discover
[14:52] Andrew Berezovskyi (KTH): Andrew: agree, just trying to accomod
Jim's discovery requirement
[14:54] Andrew Berezovskyi (KTH): Jim: what if we had the LDPC MUST, clients
would check for LDPC and if none exists, you check for the oslc membership,
finally, go for rdfs. Nick: RQM, DNG apps differ in the predicates; clients
are already complicated because the spec was imprecise.
[14:56] Andrew Berezovskyi (KTH): David: would require verbose triples
in the response. Jim: nothing esp. bad with this, there are some cases.
[14:57] Andrew Berezovskyi (KTH): Jim: is MUST/SHOULD on LDPC consistent
here with the rest of the document?
[14:57] Andrew Berezovskyi (KTH): Jim: LQE uses rdf:member
[14:57] Andrew Berezovskyi (KTH): Nick: LQE is not a reference here
[14:58] Andrew Berezovskyi (KTH): David: the Q is whether LDPC requirement
should be upgraded to a MUST or remain a SHOULD.
[14:59] Andrew Berezovskyi (KTH): David proposes a vote whether whether
the LDPC requirement should be upgraded to a MUST.
[15:01] Nick Crossley (IBM): Propose that the spec say a query result MUST
be an LDPC - and that the subsequent requirements fit in with that (for
example, by using appropriate LDPC properties to use rdfs:member as a membership
predicate by default)
[15:02] David Honey (Persistent/IBM): +1
[15:02] Jim Amsden: 0
[15:02] Andrew Berezovskyi (KTH): 0
[15:02] David Honey (Persistent/IBM): Seconded
[15:02] Nick Crossley (IBM): Nick: +1
[15:02] Martin Sarabura: +1
[15:03] Andrew Berezovskyi (KTH): Motion carried 

Given Nick's concern that this makes the Query 3.0 spec incompatible with
most implementations (an object he stated in that meeting), we may want
to reconsider. I'd like to discuss this in today's meeting so I can wrap
up the Query spec editorial work. This is the only open issue I am aware
of. 

Best regards,
David
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