Dave, Not sure why there is much difference.
It would be <ems:ProjectList xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; xmlns:dc="http://purl.org/dc/terms/"; xmlns:ems=" http://open-services.net/software-metrics/"; rdf:about="http://braintwistors.example.com/ems10/Project";> <ems:memberProject rdf:resource=" http://braintwistors.example.com/ems10/Project/2009"; /> </ems:ProjectList> vs.> <rdf:RDF> <ems:ProjectList xmlns:rdf=".http://www.w3.org/1999/02/22-rdf-syntax-ns#"; xmlns:dc="http://purl.org/dc/terms/"; xmlns:ems=" http://open-services.net/software-metrics/"; rdf:about="http://braintwistors.example.com/ems10/Project";> <ems:memberProject rdf:resource=" http://braintwistors.example.com/ems10/Project/2009"; /> </ems:ProjectList> </rdf:RDF>: The former one is more natural for representing a resource as the same way other resources are represented. I like to see using <rdf:RDF> as an exception only. i.e. in cases we can't do without. Tack Tong IBM Rational software [email protected] 905-413-3232 tie line 313-3232 ------------------------------ Message: 5 Date: Mon, 26 Apr 2010 15:08:36 -0400 From: Dave <[email protected]> To: Arthur Ryman <[email protected]> Cc: oslc-core <[email protected]>, [email protected] Subject: Re: [oslc-core] Example of a self-subject query capability representation? Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1 I think the differences in format are pretty different. In one case you have a response that contains a sequence of resource representations, each with properties, and in the other case you get one resource with a multi-valued property that has resource values-types. Conceptually, this may make sense but I think it is pretty hard to explain to consumer and provider implementations. Can't we just have one format of query response? - Dave On Mon, Apr 26, 2010 at 2:58 PM, Arthur Ryman <[email protected]> wrote: > Dave, > > It is very easy to convert the format of a single-subject response into a > multi-subject reponse that just has one subject. You merely put the > single-subject response inside <rdf:RDF> ... </rdf:RDF>. I don't think > this is a big burden for parsers (i.e. to logically supply rdf:RDF if it > is missing). > > The single-subject response is similar to the representation you get from > an HTTP GET on a resource URL without any query parameters, and that one > has no rdf:RDF. On the other hand, a multi-subject response MUST in > general start with rdf:RDF. ?So I think we need both (unless we are happy > requiring ALL RDF/XML representations to start with rdf:RDF). > > > Regards, > ___________________________________________________________________________ > > Arthur Ryman, PhD, DE > > > Chief Architect, Project and Portfolio Management > > IBM Software, Rational > > Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063 > Twitter | Facebook | YouTube > > > > > > > > From: > Dave <[email protected]> > To: > oslc-core <[email protected]> > Date: > 04/26/2010 02:38 PM > Subject: > Re: [oslc-core] Example of a self-subject query capability representation? > Sent by: > [email protected] > > > > Thanks Arthur, > > That is very helpful and I think I understand how single-subject query > responses are formed. > > My next question is this: is it possible for us to continue to have > two different conceptual types of queries (single and multi-subject) > but to use the very exact same response representation for both? This > would be very helpful to clients, who would not have to maintain two > separate code paths for parsing OSLC query results. > > - Dave > > > > On Mon, Apr 26, 2010 at 2:27 PM, Arthur Ryman <[email protected]> wrote: >> Dave, >> >> The example query response in the core spec is a mult-subject response >> since it begins with <rdf:RDF>. >> >> A "container" resource or a "collection" resource is a plain old > resource >> that has some multi-valued property that we regard as a membership >> property. The values of this property are the members of the >> container/collection/list/... We can filter, sort, etc. this set of >> members using "member list pattern" queries. >> >> The core spec links to examples of self-subject query responses [1]. For >> example, the resource ?http://braintwistors.example.com/ems10/Project is > a >> container resource that contains the list of all project resources. It > has >> a multi-valued property ems:memberProject that refers to the member >> projects. >> >> <ems:ProjectList xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; >> ? xmlns:dc="http://purl.org/dc/terms/"; xmlns:ems=" >> http://open-services.net/software-metrics/"; >> ? rdf:about="http://braintwistors.example.com/ems10/Project";> >> ? <dc:title>BrainTwistors Corp. Project List</dc:title> >> ? <dc:description> >> ? ? ?This is the list of all Project resources contained in >> ? ? ?BrainTwistors Corp. MetricServer web application. >> ? ? ?</dc:description> >> ? <ems:service rdf:resource="http://braintwistors.example.com/ems10"; /> >> >> ? <ems:memberProject rdf:resource=" >> http://braintwistors.example.com/ems10/Project/2009"; /> >> ? <ems:memberProject rdf:resource=" >> http://braintwistors.example.com/ems10/Project/3707"; /> >> ? <ems:memberProject rdf:resource=" >> http://braintwistors.example.com/ems10/Project/3998"; /> >> ? <!-- >> ? ? ?Other members of this ProjectList resource have been omitted for >> ? ? ?brevity. >> ? --> >> </ems:ProjectList> >> >> The following query filters the project list: >> >> http://braintwistors.example.com/ems10/Project?oslc.where=dc:identifier= >> "2009" >> >> The query response is: >> >> <ems:ProjectList xmlns:rdf=" http://www.w3.org/1999/02/22-rdf-syntax-ns#>>" >> ? xmlns:dc="http://purl.org/dc/terms/"; xmlns:ems=" >> http://open-services.net/software-metrics/"; >> ? rdf:about="http://braintwistors.example.com/ems10/Project";> >> ? <ems:memberProject rdf:resource=" >> http://braintwistors.example.com/ems10/Project/2009"; /> >> </ems:ProjectList> >> >> [1] >> > http://open-services.net/bin/view/Main/OslcSimpleQuerySemanticsV1#Examples >> Regards, >> > ___________________________________________________________________________ >> >> Arthur Ryman, PhD, DE >> >> >> Chief Architect, Project and Portfolio Management >> >> IBM Software, Rational >> >> Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063 >> Twitter | Facebook | YouTube >> >> >> >> >> >> >> >> From: >> Dave <[email protected]> >> To: >> oslc-core <[email protected]> >> Date: >> 04/26/2010 12:45 PM >> Subject: >> [oslc-core] Example of a self-subject query capability ?representation? >> Sent by: >> [email protected] >> >> >> >> I need a little help understanding the most recent changes in the >> Query Capabilities section of the spec. We now have two types of query >> capabilities, multi-subject and self-subject but we only illustrate >> multi-subject queries in our examples. I'm trying to understand what a >> self-subject query response would look like. Here's how it is >> described in the Core spec: >> >> "The RDF/XML representation of the query result begins with a node >> element whose rdf:about attribute value is equal to the base URI. >> Typically, the base URI is a container resource that may have a long >> list of members, e.g. the list of all defects in a bug tracking >> system. Since the list may contains hundreds of thousands of members, >> queries are used to filter the list for members that satisfy certain >> conditions, e.g. the bugs that have high priority and were created >> this week." >> >> I don't know what "the base URI is a container resource that may have >> a long list of members" means. Are we using a multi-valued property >> here to hold the resources that match the query? Tack or Arthur, would >> one of you please provide a simple example of a self-subject query >> response? >> >> Thanks, >> - Dave >> >> _______________________________________________ >> Oslc-Core mailing list >> [email protected] >> http://open-services.net/mailman/listinfo/oslc-core_open-services.net >> >> >> >> > > _______________________________________________ > Oslc-Core mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net > > > > ------------------------------ _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net End of Oslc-Core Digest, Vol 3, Issue 27 ****************************************
