After re-reviewing the section on Member List Pattern from Query section [1], I would recommend this approach:
In cases where Shape definition is not provided, use the default shape definition for query results where: Default membership property of <oslc:result> (notice singular form of results) on the resource type of <oslc:QueryResult> Note: for JSON the default would be to utilize "oslc:results" (notice plural form of result) for JSON array name (see thread below) Here's what it would look like in RDF/XML: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; xmlns:dcterms="http://purl.org/dc/terms/"; xmlns:oslc="http://open-services.net/ns/core#";> <oslc:ResponseInfo rdf:about=""> <dcterms:title>Blog Service Query Results for term [remote]</dcterms:title> </oslc:ResponseInfo> <oslc:QueryResult rdf:about=""> <oslc:result rdf:resource="http://example.com/blogs/comment/5"; /> <oslc:result rdf:resource="http://example.com/blogs/comment/4"; /> <oslc:result rdf:resource="http://example.com/blogs/comment/1"; /> <oslc:result rdf:resource="http://example.com/blogs/comment/2"; /> <oslc:result rdf:resource="http://example.com/blogs/comment/3"; /> <!-- etc. etc. --> </oslc:QueryResult> </rdf:RDF> I'd like to discuss this during tomorrow's core WG call to see if this could be incorporated into the query result representation guidance. [1] http://open-services.net/bin/view/Main/OSLCCoreSpecQuery?sortcol=table;up=#Member_List_Patterns Thanks, Steve Speicher | IBM Rational Software | (919) 254-0645 Patrick Streule <[email protected]> wrote on 08/03/2010 12:38:36 PM: > From: Patrick Streule <[email protected]> > To: Steve K Speicher/Raleigh/IBM@IBMUS > Cc: [email protected] > Date: 08/03/2010 12:44 PM > Subject: Re: [oslc-core] Proposed change to JSON formatting rules > for Query responses > > > I would expect with our approach to resource formats now, we could simply > > > represent the query response as: > > > > ... > > > > Thus eliminating the intermediate query resource and property, just > > include the resources in the response. > > That would be even simpler, but I think it interferes with the Resource > Pagination part of the core spec. > Having a 'QueryResult' resource with 'result' properties makes query > results just a specific case of Resource Pagination (the properties -- all > the same in this case -- are continued on additional pages). > > There would be a corner case (a bit constructed, admittedly): If the page > size is 1, a client couldn't tell if the representation means that the > properties of the single resource are continued on additional pages, or if > there are additional resources on these pages: > > <rdf:RDF > xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; > xmlns:dcterms="http://purl.org/dc/terms/"; > xmlns:oslc="http://open-services.net/ns/core#"; > xmlns:oslc_blog="http://open-services.net/ns/bogus/blogs#";> > > <oslc:ResponseInfo rdf:about="http://example.com/query?oslc.from [...] > entry/1>"> > <dcterms:title>Blog Service Query Results for term > [remote]</dcterms:title> > <oslc:nextPage rdf:resource="..."/> > </oslc:ResponseInfo> > > <oslc_blog:Comment rdf:about="http://example.com/blogs/comment/5";> > <!-- Comment propery values, etc. --> > <dcterms:title>Comment #5</dcterms:title> > </oslc_blog:Comment> > > </rdf:RDF> > > This representation could mean > 1) There are more properties of oslc_blog:Comment on the next page > 2) There are more oslc_blog:Comment resources on the next page > > Regards, > Patrick > > > > > > > > Some concerns that I have: > > > > > > 1) Wouldn't these resources/properties also have to be spec'd by the > > > domains? I.e. the CM spec would have to define e.g. a > > > 'oslc_cm:ChangeRequestQueryResult' resource. Currently, I don't see > > > anything about query results e.g. in the CM, QM and RM specs. > > > > I have an outstanding action to add definition of this for "oslc:results" > > > for JSON query results. > > I made an assumption about the RDF/XML and XML form (as illustrated > above) > > that I need to get clarification on, where I thought we didn't need to > > define query resources for the response. > > > > > 2) Does a domain specific query result resource provide added value > over > > a > > > generic 'oslc:QueryResult' resource with 'oslc:results' properties? I > > see > > > that we get "Type Safety" by the domain specific resources/properties, > > but > > > the convenience of a common format for query results seems to outweigh > > > that, IMO. > > > > > > Thanks, > > > Patrick > > > > > > > > > > > > > > > From: Steve K Speicher <[email protected]> > > > > > > To: [email protected] > > > > > > Date: 07/27/2010 10:57 PM > > > > > > Subject: [oslc-core] Proposed change to JSON formatting rules > > > for Query responses > > > > > > > > > > > > > > > > > > > > > Current JSON guidance [1] doesn't address what the result array name > > > should be. > > > > > > I recommend that we use "oslc:results" array, like for delegated UIs > [2] > > > > > > See also example at [3], how does a consumer know to look for array > > named > > > "oslc_blog:comment" in this example. I think it would be best to use a > > > general OSLC property. > > > So this example would become: > > > "oslc:results" : [{ > > > "oslc:qname" : "oslc_blog:BlogComment", > > > "rdf:resource" : "http://example.com/blogs/comment/346";, > > > }, > > > > > > [1] > > > http://open-services.net/bin/view/Main/ > > > OSLCCoreRepresentationsGuidance#Guidelines_for_JSON > > > > > > [2] > > > http://open-services.net/bin/view/Main/ > > > OslcCoreSpecification#Delegated_User_Interface_Dialogs > > > > > > [3] > > > > > > http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixD#Query_Resource > > > > > > > > Thanks, > > > Steve Speicher | IBM Rational Software | (919) 254-0645 > > > > > > > > > _______________________________________________ > > > > >
