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


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

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

    Description: 
The description of the query result could do with at least one example. 

The current design seems to be that to interpret the container, you have to get the resource shape of the query capability, and then look for an oslc:property with oslc:isMemberProperty with value true to see what predicate defines the membership. There's no requirement for one to be so marked in the resource shape, or that there is a maximum of one. If a resource shape doesn't exist, or has no oslc:property specified with oslc:isMemberProperty=true,then it's not clear what the default is. There is a suggestion in the core vocabulary it might be rdfs:member, but no mention of this in the query spec itself.

What would be better would be to use an LDPC. For backwards compatibility, if the container defined the membership predicate the same as any defined in the query capability resource shape, then both means of discovering the memership predicate would work. This allows an implementation to do any of:
1) Use an ldp:BasicContainer and define ldp:contains as the membership property in the query capability resource shape.
2) Use an ldp:DirectContainer with a ldp:hasMemberRelation that uses the same predicate as the membership property in the query capability resource shape.

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.

  was:
The description of the query result could do with at least one example. 

The current design seems to be that to interpret the container, you have to get the resource shape of the query capability, and then look for an oslc:property with oslc:isMemberProperty with value true to see what predicate defines the membership. But if a resource shape doesn't exist, then you have no idea how the members are represented. There's no requirement for one to be so marked in the resource shape, or that there is a maximum of one. This is a poor design.

What would be better would be to use an LDPC. For backwards compatibility, if the container defined the membership predicate the same as any defined in the query capability resource shape, then both means of discovering the memership predicate would work. This allows an implementation to do any of:
1) Use an ldp:BasicContainer and define ldp:contains as the membership property in the query capability resource shape.
2) Use an ldp:DirectContainer with a ldp:hasMemberRelation that uses the same predicate as the membership property in the query capability resource shape.

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.


> Query result container
> ----------------------
>
>                 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 design seems to be that to interpret the container, you have to get the resource shape of the query capability, and then look for an oslc:property with oslc:isMemberProperty with value true to see what predicate defines the membership. There's no requirement for one to be so marked in the resource shape, or that there is a maximum of one. If a resource shape doesn't exist, or has no oslc:property specified with oslc:isMemberProperty=true,then it's not clear what the default is. There is a suggestion in the core vocabulary it might be rdfs:member, but no mention of this in the query spec itself.
> What would be better would be to use an LDPC. For backwards compatibility, if the container defined the membership predicate the same as any defined in the query capability resource shape, then both means of discovering the memership predicate would work. This allows an implementation to do any of:
> 1) Use an ldp:BasicContainer and define ldp:contains as the membership property in the query capability resource shape.
> 2) Use an ldp:DirectContainer with a ldp:hasMemberRelation that uses the same predicate as the membership property in the query capability resource shape.
> 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]