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

David Honey created OSLCCORE-102:

             Summary: 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 the oslc:isMemberProperty 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.

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

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