Re: Yet more candidates for requriements and design objectives [w as Re: possible regrets]

Hello,

#sorry for the delay in responding...

Andy:
> > 1 - Getting just the number of the answers (R)
> > 2 - Sorting of the answers (R)
> > 3 - Answer in N-bytes (R)
>
> Could you say why these are potential *requirements* (that is, language
> must-haves)?

1. Getting just the number of the answers

In cases where the cost of sending/receiving all the results is very high,
like in a case of web page  search, the user should given the option of
deciding the limit of the number of the results to be retrieved or
tuning his/her query to get less results.

It is indispensable especially when user is charged money for getting a
record.

2. Sorting of the answers

> sort() imposes a cost on the server and has significant impact on
> implementations.  While I see that as a useful feature in a language, I
> don't see it as a necessity for the recommendation.

Without means to specify sorting order, limiting the number of the result
(3.10)
would be almost meaningless to the end-user.

And by using the sort functionality, the user can query queries referring to
an order, for example,
"the fastest way from here to JFK airport" or "the best three selling CD's
in this week",
the queries that are very common in our daily life.

3. Answer in N-bytes

Well, this is added for client systems which has a fixed-size structure for
receiving the results.
This would be useful escpecially where the query is executed locally (on the
same machine).

> > 4 - Searching Reified triples (O)
> > 5 - Conditioning on meta-data (O)
>
> Andy

Regards,
Yoshio Fukushige
fukushige.yoshio@jp.panasonic.com



>
>
>
> -------- Original Message --------
> > From: Yoshio Fukushige <>
> > Date: 29 June 2004 16:03
> >
> > Hi all,
> >
> > I know now the UC&R document is freezed,
> > but let me tell you I (re)wrote a document on
> > yet more candidates for requirements and design objectives.
> >
> > Almost all of them were presented you in an informal style [1],
> > but some of them were changed their title, some were striked,
> > and all of them are written in a manner in the UC&R document.
> >
> > I put it at http://www.w3.org/2004/06/29-Yoshio/DAWG-addenda040628.html,
> > while I enclose a (less readable?) text version here.
> >
> > Some of them(1, 2, 3) are obvious and just for the completeness of the
> > requirements,
> > but the rest (4, 5) are ones we missed in our discussion, I think.
> >
> > [1]
> > http://lists.w3.org/Archives/Public/public-rdf-dawg/2004AprJun/0635.html
> >
> > ------------text version from here --------------
> > The followings are the proposed additional candidates for the
> > requirements (marked
> > with "(R)")and design objectives (marked with "(O")). Striked are the
> > ones
> > rejected by the author in reconsideration.
> >
> > (1) Getting just the number of the answers (R)
> >
> > (2) Sorting of the answers (R)
> >
> > (3) Answer in N-bytes (R)
> >
> > (4) Searching Reified triples (O)
> >
> > (5) Conditioning on meta-data (O)
> >
> > (6) Premise (Striked)
> >
> > (7) Conditional solution (Striked)
> >
> > (8) Limit in Time (Striked)
> >
> >
> > (1) Getting just the number of the answers (R)
> >
> > It must be possible for user to get just the number of the query
> > answers.
> >
> > Implicitly presupposed in 3.10 Result Limits, 3.11 Iterative Query and
> > 3.12
> > Streaming Results?
> >
> > (2) Sorting of the answers (R)
> >
> > It should be possible to specify a means to sort the answers for the
> > query.
> >
> > Implicitly presupposed in 3.10 Result Limits, 3.11 Iterative Query and
> > 3.12
> > Streaming Results?
> >
> > (3) Answer in N-bytes (R)
> >
> > The server should return its answer in less than a prespecified number
> > of
> > bytes.
> > The server should tell the client whether the answer it gives is the
> > whole
> > answer or it is snipped.
> >
> > A variant of the requirement 3.10 Result Limits
> >
> > (4) Searching Reified triples (O)
> >
> > It should be possible to specify whether reified triples should be
> > regarded
> > as
> > an assertion (with additional information)
> >
> > [NOTE] There could be KB systems where reification may be used when
> > additional
> > information should be attached to an assertion.
> >
> > (5) Conditioning on meta-data (O)
> >
> > It should be possible to specify which triples should or should not be
> > used
> > in
> > searching. The specification may refer to the date of the creation of
> > the
> > data,
> > the creator of the data, or other meta-data attatched to the data.
> >
> > e.g. "Use data (triples) created within 1 year only." or "Don't use data
> > created
> > before 1 year back from now"
> >
> > (6) Premise (Striked)
> >
> > Already included in 4.5 Aggregate Query
> >
> > [[
> > we do lots of queries with premises in our daily life.
> >
> > e.g. Are Mary and Bob friends of a friend if Jane is a friend of Mike?
> > e.g. What is the lowest price for the product A if shop B does
> > discounts by 20
> > points from their normal price?
> > ]]
> >
> > (7) Conditional solution (Striked)
> >
> > It is just the matter of the interpretation of the results.
> >
> > [[
> > It must be possible for query results to be returned in conditional
> > form.
> >
> > e.g. To the question "How long does it take from Fujisawa to
> > Shinjuku?," the
> > system may answer:
> > "If you take Odakyu line, it'll be 52 minutes, and if you take JR line,
> > it'll be
> > 68 minutes..."
> > ]]
> >
> > (8) Limit in Time
> >
> > Little use or protocol issue
> >
> > [[
> > The server should not spend over a prescribed amount of time attempting
> > the
> > query or inference.
> >
> > -> http://www.w3.org/2001/11/13-RDF-Query-Rules/terms#protocol_timeLimit
> >
> > "Give me all the answer found in N seconds"
> > ]]
> >
> >
> > ------------text version to here --------------
> >
> > Bests,
> > Yoshio Fukushige
> > fukushige.yoshio@jp.panasonic.com
> >
> >
> > ----- Original Message -----
> > From: "Yoshio Fukushige" <fukushige.yoshio@jp.panasonic.com>
> > To: <public-rdf-dawg@w3.org>
> > Sent: Tuesday, June 22, 2004 4:26 PM
> > Subject: possible regrets
> >
> >
> > >
> > > Dear all,
> > >
> > > I'm very sorry but I have to send possible regrets for today's
> > > telecon for my bad health condition.
> > >
> > > I wanted to work out on the candidates for requriements or design
> > > objectives I proposed, i.e. to rewrite them in the form as others,
> > > but I have to postpone it till next telecon.
> > >
> > > Best,
> > > Yoshio.
>

Received on Tuesday, 6 July 2004 05:34:39 UTC