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

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, 29 June 2004 11:03:13 UTC