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: [OASIS Issue Tracker] (OSLCCORE-102) Query result container issues in Query spec


     [ https://issues.oasis-open.org/browse/OSLCCORE-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Honey updated OSLCCORE-102:
---------------------------------

    Proposal: 
1) Have the query specification state that an oslc:QueryCapability SHOULD declare an oslc:resourceShape. With a resource shape, query builders can discover what member resource properties are available.

2) Have the query specification state that resource shape referenced by the query capability SHOULD denote one, and only one, OSLC property with oslc:isMemberProperty "true"^^xsd:boolean and that it SHOULD reference exactly one oslc:valueShape that describes member properties. It should define the semantics and deal with https://issues.oasis-open.org/browse/OSLCCORE-145.

3) The spec should explicitly describe the query result container and provide examples. The spec should state that the query result container should be an LDPC, and that the query response contains the LDPC headers that declares that as described in the LDPC W3C spec.

4) If a query capability does not declare an oslc:resourceShape, or that referenced shape defines rdfs:member with isMemberProperty=true, then the query result container SHOULD use both rdfs:member and ldp:contains, and SHOULD use an ldp:DirectContainer with ldp:membershipPredicate rdfs:member.  This maintains backwards compatibility with Query 2.0, but moves the spec forwards to be consistent with 3.0 LDPC usage.

5) If a query capability does reference a resource shape, the spec should  state that an implementation MAY choose to declare ldp:contains as the isMemberProperty=true. The advantage of this is that the query result container only need use ldp:contains (saving rdfs:member triples), and the container can be an ldp:BasicContainer.

  was:
1) Have the query specification state that an oslc:QueryCapability SHOULD declare an oslc:resourceShape. Without it, query buildersd would have no means of discovering what member resource properties are available.

2) Have the query specification state that resource shape referenced by the query capability SHOULD denote one, and only one, OSLC property with oslc:isMemberProperty "true"^^xsd:boolean and that it SHOULD reference exactly one oslc:valueShape that describes member properties. It should define the semantics and deal with https://issues.oasis-open.org/browse/OSLCCORE-145.

3) The spec should explicitly describe the query result container and provide examples. The spec should state that the query result container should be an LDPC, and that the query response contains the LDPC headers that declares that as described in the LDPC W3C spec.

4) If a query capability does not declare an oslc:resourceShape, or that referenced shape defines rdfs:member with isMemberProperty=true, then the query result container SHOULD use both rdfs:member and ldp:contains, and SHOULD use an ldp:DirectContainer with ldp:membershipPredicate rdfs:member.  This maintains backwards compatibility with Query 2.0, but moves the spec forwards to be consistent with 3.0 LDPC usage.

5) If a query capability does reference a resource shape, the spec should  state that an implementation MAY choose to declare ldp:contains as the isMemberProperty=true. The advantage of this is that the query result container only need use ldp:contains (saving rdfs:member triples), and the container can be an ldp:BasicContainer.


> Query result container issues in Query spec
> -------------------------------------------
>
>                 Key: OSLCCORE-102
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-102
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Task
>          Components: Query
>            Reporter: David Honey
>            Assignee: James Amsden
>
> The description of the query result could do with at least one example.
> The current specification does not describe any container, but related guidance documents do. The current position is that an oslc:QueryCapability may reference Zero-or-one oslc:resourceShape. If specified, that resource shape is the resource shape of the query result container, and it MUST denote at least one OSLC property as being a member property using the oslc:isMemberProperty. That predicate is defined in OSLC Core 3.0 Resource shapes, but was not described in the query spec. If a query capability does not reference a resource shape, then the current [undocumented] behaviour is to use rdfs:member.
> Some implementations also provide a resource shape for the query result members by providing an oslc:valueShape for the OSLC property that has oslc:isMemberProperty set to true. However, the semantics of that referenced shape is ambiguous - see https://issues.oasis-open.org/browse/OSLCCORE-145.
> In many cases, both OSLC Core and OSLC Configuration Management provide other containers, and these are specified as LDPCs. These LDPCs have some similarity with a query base except that they do not support oslc.where or oslc.searcdhTerms. We should align the query result container with LDPCs. This has the advantage that it's backwards compatible with OSLC 2.0 query, but has the usual semantics of LDPCs widely used in OSLC Core 3.0. 



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


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