RE: Vocabulary for result sets

Libby,

> you might also get multiple valid resultsets per query, 
> depending on the
> power of the KB.

I'm not sure which way round you mean "multiple valid resultsets per query":
the vocabulary allows multiple solutions per result table.  And also
multiple result sets per result graph because it is rooted from a single
node.  The example uses <> as that node but there is no reason it has to be
that; you could have a bNode there, and have another starting bNode
somewhere else.

Could you give an example of when there would be multiple result sets?  I
can image a "query request" to actually consist of a series of "queries" all
of which should be executed.

	Andy

> -----Original Message-----
> From: Libby Miller [mailto:Libby.Miller@bristol.ac.uk] 
> Sent: 24 January 2003 15:05
> To: Seaborne, Andy
> Cc: 'Graham Klyne'; 'public-esw@w3.org'
> Subject: RE: Vocabulary for result sets
> 
> 
> 
> you might also get multiple valid resultsets per query, 
> depending on the
> power of the KB.
> 
> On Fri, 24 Jan 2003, Seaborne, Andy wrote:
> 
> >
> > > -----Original Message-----
> > > From: Graham Klyne [mailto:GK@NineByNine.org]
> > > Sent: 23 January 2003 21:12
> > > To: Seaborne, Andy
> > > Cc: 'public-esw@w3.org'
> > > Subject: Re: Vocabulary for result sets
> > >
> >
> > ...
> >
> > >
> > > Hmmm... I wonder of there should be links to, or 
> identifiers of, the
> > > knowledge-base and query used, so that valid results from
> > > different queries
> > > can be differentiated.  In practice, I think this kind of
> > > testing is a
> > > relatively closed-world activity, so maybe it doesn't matter.
> > >
> >
> > Graham,
> >
> > Good point.  A number of properties to annotate the result 
> set would be
> > good.  Of course, nothing stops any properties being added 
> ... but putting
> > them in the vocabulary encourages their use.
> >
> > Are there any suitable properties from other vocabularies to reuse?
> >
> > Also - this could be the result from a query, not just 
> recording information
> > for a testcase.  In this case, we still have a 
> query->single graph approach
> > but the presentation of the results isn't a subgraph of the 
> original KB, but
> > an encoding of the variable bindings.  Each solution can be 
> substituted into
> > the pattern for the query to generate a sequence of 
> subgraphs, each of which
> > satisfy the query but the result set graph does not feel 
> like knowledege
> > extraction anymore.
> >
> > 	Andy
> >
> >
> >
>

Received on Friday, 24 January 2003 10:21:38 UTC