Dave, 2. * Are there different parameters that apply with single vs. multi? I could not see any, but perhaps I did not read closely enough.
No, all the query parameters apply to both types of query capability. The base URL for a mutli-subject query capability represents a SET of base URLs for self-subject query capabilities The result for a multi-subject query is the UNION of the results for each self-subject which then gets sorted and limited as a whole. 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 04:51 PM Subject: Re: [oslc-core] Example of a self-subject query capability representation? Sent by: [email protected] Thanks Arthur. I'm going to have to think on this some more. We've got a ways to go before this is dumbed down to my level ;-) I have a couple more questions, if you please: * Why would you use a multi-subject query vs. a single-subject query? I would like to spell this out in the section that defines the two types. * Are there different parameters that apply with single vs. multi? I could not see any, but perhaps I did not read closely enough. * If you define a single-subject query must you also define the "shape" of the resulting response And specifically, how did we know, in Tack's example, that the root element would be <ems:ProjectList>? Thanks, - Dave On Mon, Apr 26, 2010 at 3:44 PM, Arthur Ryman <[email protected]> wrote: > The most frequent case would be a self-subject query since any resource > can be its base URL. The Query Capabilities then simply identify a few > root resources to start off the discovery process. That is what Reporting > is supporting. > > The multi-subject case allows some additional use cases (e.g. full text > search across all resources, search across multiple lists of the same > type, e.g. different project areas) but perhaps these are not worth > specifying in the core. If no one has a compelling need for this, I am OK > with dropping it. Perhaps the more powerful types of query should be > handled by an RDF index running full SPARQL. > > 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: > Arthur Ryman/Toronto/IBM@IBMCA > Cc: > oslc-core <[email protected]>, > [email protected] > Date: > 04/26/2010 03:09 PM > Subject: > Re: [oslc-core] Example of a self-subject query capability representation? > > > > 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
