[oslc-core] Proposed change to JSON formatting rules for Query responses

Steve K Speicher sspeiche at us.ibm.com
Wed Aug 4 13:49:19 EDT 2010


Here's the what was discussed at today's Core WG meeting and proposed 
changes:

If no Query Resource Shape information is available, use defaults of 
<rdf:Description> and <rdfs:member>

<rdf:RDF 
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
   xmlns:dcterms="http://purl.org/dc/terms/"
   xmlns:oslc="http://open-services.net/ns/core#">

     <oslc:ResponseInfo rdf:about="
http://example.com/myquery?oslc.query=oslc_cm.inprogress=true">
         <dcterms:title>Blog Service Query Results for term 
[remote]</dcterms:title>
     </oslc:ResponseInfo>
 
     <rdf:Description rdf:about="http://example.com/myquery">
 
        <rdfs:member rdf:resource="http://example.com/blogs/comment/5" />
        <rdfs:member rdf:resource="http://example.com/blogs/comment/4" />
        <rdfs:member rdf:resource="http://example.com/blogs/comment/1" />
        <rdfs:member rdf:resource="http://example.com/blogs/comment/2" />
        <rdfs:member rdf:resource="http://example.com/blogs/comment/3" />
 
       <!-- etc. etc. -->
 
     </rdf:Description>

</rdf:RDF>

For JSON, I think leaving the oslc:results is fine in this case since we 
don't have a RDF standard for JSON we are based on

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645


Steve K Speicher/Raleigh/IBM wrote on 08/03/2010 07:20:45 PM:

> From: Steve K Speicher/Raleigh/IBM
> To: oslc-core at open-services.net
> Date: 08/03/2010 07:20 PM
> Subject: Re: [oslc-core] Proposed change to JSON formatting rules 
> for Query responses
> 
> 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 <patrick_streule at ch.ibm.com> wrote on 08/03/2010 
12:38:36 PM:
> 
> > From: Patrick Streule <patrick_streule at ch.ibm.com>
> > To: Steve K Speicher/Raleigh/IBM at IBMUS
> > Cc: oslc-core at open-services.net
> > 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 <sspeiche at us.ibm.com>
> > > >
> > > >   To:         oslc-core at open-services.net
> > > >
> > > >   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
> > > >
> > > >
> > > > _______________________________________________
> > >
> > >
> > 





More information about the Oslc-Core mailing list