Re: New requirement: disjunction

Hello,

As a follow-up for my comments in the f2f meeting on the current wording of
the disjunction requirement:
#I wish I could have said this in good English


The original wording says:

[[[
The query language must include the capability to restrict matches on a
queried graph based on a disjunction of graph patterns, at least one of
which must be satisfied by the query.
]]]

My first concern is that the notion of "a disjunction of graph patterns" is
not clear.

It cannot mean "the union of the graph patterns," for the union of the
triples means
the conjunction of the conditions represented by the graph patterns
(here, the word "union" is used in the same way it is used in the set
theory).

However, the notion of disjunction goes usually with the notion of union, so
at least
it is quite confusing.

Is it a graph pattern among those in the query that are connected
by one or more disjunction oprator(s)? (*)
But I'm not sure if it can be  called "a disjunction" itself.

Second,  I'm puzzled by the article "a" in the phrase "a disjunction."
The only possible reading is  the (*) above, but I'm not sure if such
wording is possible.

Third, I can't find the anteceedent of the relative pronoun "which" in
"at least one of which must be satisfied by the query."

If it is "graph patterns," then I cannot understand what is meant by
"one of the graph patterns must be satisfied by the query."

If the antecedent is "matches," I don't think the matches are well-specified
in a situation where
"at least one of the matches must be satisfied by the query,"
where the matches can contain arbitrary thing.

I enven would like to say that I don't understand  what is meant when saying
"something is satified by the query."

A query is a thing to be satified, rather than a thing to satify something
else, isn't it?

As such the original wording is quite confusing.

So, my alternative suggestion is
[[[
The query language must include the capability to restrict matches on a
queried graph to match at least one of the graph patterns in the query
connected by one or more disjunction operator(s).
]]]

What do you think?

Best,
Yoshio
fukushige.yoshio@jp.panasonic.com


----- Original Message ----- 
From: "Rob Shearer" <Rob.Shearer@networkinference.com>
To: <public-rdf-dawg@w3.org>
Sent: Thursday, July 15, 2004 8:22 AM
Subject: New requirement: disjunction



Following on from the general support (voiced by at least three members
of the group- Tucana, Network Inference, and Mindlab) for the inclusion
of an 'OR' operator in our query language, here is a vague stab at a
wording for that requirement:

The query language must include the capability to restrict matches on a
queried graph based on a disjunction of graph patterns, at least one of
which must be satisfied by the query.


This wording is intended primarily to play well with the 'Graph Pattern
Matching' requirement, which I believe is the way we currently require
conjunction. (If others feel that requirement does not require
conjunction, I think it's worth talking about sooner rather than later.)

I believe that the above words require support for disjunctive normal
form (an OR of ANDs), which implies the ability to deal with disjunction
of triples in general. Admittedly the 'pattern' language along with
top-level disjunction is a bit of a roundabout way to get to a
requirement for "tests for the existence of a triple, connected with AND
and OR", but my belief is that they amount to the same thing.

Note that this requirement does NOT necessarily require a simple syntax.
My interpretation is that the ability to write two queries and then join
the results with some kind of UNION operator could probably be made to
fulfill this objective (with the 'easily written by users' objective
mitigating against onerous syntax for commonly-used constructions).

I also believe that if we manage to support our "Non-existent Triples"
objective, the three come together to offer support for arbitrary
boolean combinations of triple-existence predicates.

Received on Tuesday, 20 July 2004 03:39:04 UTC