OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

The motivation behind using LDPCs was for consistency with OSLC Core 3.0's recommendation that containers be LDPCs. We already have specifications such as Configuration Management describe LDPCs, and a GET on those are almost certainly going to be implemented as a query. One might imagine that an implementation would want to share code for producing the response for this usage and for query usage. The query refers to resource paging in core, and that section describes both OSLC 2.0 paging and LDP paging. It would be inconsistent if query then described and showed examples that were not LDPCs.

The only open issue we have currently is whether the LDPC is a MUST (which was voted on and passed) or a SHOULD (what I originally had), and that arose because Nick raised the topic in his review comments but could not recall voting in favour of MUST in the meeting on 2018-07-19.

We have already had at least 3 rounds of discussion on this topic, and at no time did anyone propose dropping the use of LDPCs from the query spec. We have to reach a conclusion so we can move forwards, and I thought we had already achieved that through earlier review and a formal vote. Reconsidering the MUST/SHOULD decision only involves a trivial change to the spec. Given the previous vote was contentious with 2 people voting "0", one might argue there is justification in voting again on the proposal for MUST vs SHOULD. Removing all references to LDPCs is a much bigger change and might even impact core, requiring that the resource paging be split into two subsections so that query can refer to just one of the two paging mechanisms.

Jim, if you feel strongly about query using LDPCs at all, could you please submit a new issue with your proposal. Nick may be unable to participate in the meeting on 2018-10-11, and I will be unable to attend on 2018-10-18 or 2018-10-25. This means that the earliest we might discuss and vote on such a proposal is probably the meeting on 2018-11-01, and this would delay any proposal to publish the Query CSD, and maybe the core CSD,  for public review until after that.

Best regards,

From:        "Jim Amsden" <jamsden@us.ibm.com>
To:        "OSLC Core TC (oslc-core@lists.oasis-open.org)" <oslc-core@lists.oasis-open.org>
Date:        04/10/2018 20:38
Subject:        Re: [oslc-core] OSLC query, vote on query results container MUST be an LDPC
Sent by:        <oslc-core@lists.oasis-open.org>

I remain concerned that we are introducing a technical "cleanup" that doesn't really add any significant new value in the context of OSLC query, while resulting in something that we know will break all existing implementations.

If we reduce the question to whether the results of an OSLC query should be an LDPC or not, perhaps we can answer that question by asking what its URI is, what link headers it would support on OPTIONS and HEAD, etc. That's what distinguishes an LDPC, its capabilities.

It seems like OSLC query member results are not really RDF resources, or LDPCs, they're just an interchange format for returning a result set. SPARQL took a different approach, one that easily supports ordering.

I think we are on the verge of over complicating already over complicated OSLC query (especially compared to its complexity vs capability ratio) for purposes that have limited business value. I tend to think we should just pick rdf:member and be done, we don't need all the complexity that has been added by LDP or membership resources just to return a simple result set consisting of URIs.

Jim Amsden, Senior Technical Staff Member

OSLC and Linked Lifecycle Data


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

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:

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):
[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,
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

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]