|
major
technical comment: identifier length 2006-01-12T02:19:30Z
Fred Zemke Summary:
Since arbitrary sized elements (such as, URIs,
Literals, and blank node labels) need to be handled anyway, some members in
DAWG wondered whether we need to do a special case for identifier-length just
for variables. |
|
major
technical: semantics are poorly specified 2006-01-12T21:34:41Z
Fred Zemke Latest
version includes many re-writings and clean-ups. The DAWG members are
reluctant to take up additional changes in this regard at this time. |
|
major
technical: runaway queries 2006-01-12T21:37:34Z
Fred Zemke Summary:
The solution outlined in the new version of the document is along the line of
the provisional solution you suggested (that is, limiting the result to be
made up of known RDF terms). Also, the point about SELECT clause allowing
expression seems important. I need to find out as to why we are not allowing
that. |
|
major
technical: underspecified errors 2006-01-12T21:41:10Z
Fred Zemke (I
saw an ACTION ITEM for Dan Connolly to respond to this comment. In that case
the following is unnecessary.) I have
been told by other members of DAWG that it is illegal to name the same
dataset twice in FROM or FROM NAMED clauses of a query. I’d think that
protocol service behaves similarly in case the same dataset appears multiple
times in the RDF dataset specified in the invocation. If an
IRI does not identify a resource represented by a graph then I’d expect query
request would be refused using QueryRequestRefused.
The protocol document does not individually identify these errors, however. |
|
minor
technical on 5.4 Optional matching - formal definition 2006-01-12T17:31:59Z
Fred Zemke Summary:
The
definition you proposed is very clean. There is probably a minor problem in
the boundary case. I think that it needs to exclude the pathological case of
VB = empty. That change will correctly handle a case like {
?x :hasBoss :Mary . OPTIONAL { ?x :plays :Soccer } } where VA = {?x} and VB = empty. This
is a pathological case because the OPTIONAL part in this case example does
not contribute anything to the result and therefore such a graph pattern,
although valid, would yield same result as just {?x :hasBoss
:Mary} The
definition in the latest version of the document works too if it says
something like: “… S is a solution … if S is a pattern solution for the graph
pattern same as Opt(A, B) but with B considered compulsory (i.e., not
OPTIONAL), otherwise if S is a pattern solution for the graph pattern
consisting of A only.” I am
assuming that the following assumption is true: A pattern solution for a
graph pattern is a set of bindings for only those variables that are in the
graph pattern and for no other variables. This assumption is needed to ensure
that a pattern solution for A does not include a binding for a variable
contained only in B (i.e., not in A, so in VB set using your notation). If
this assumption does not hold then a pattern solution for A only may contain misleading
bindings for variables in VB. Consider the following example: { ?x :hasBoss :Mary . OPTIONAL { ?x :hasFriend
?y } } Here, if we allow { ?x=:John, ?y=:David} to be a solution for A only,
then that result may indicate that :John :hasFriend
:David . is an assertion in the RDF dataset, which
may or may not actually be the case. |
|
minor
technical on 9 Specifying RDF datasets 2006-01-12T17:33:12Z
Fred Zemke This may
be okay the way it is in the document. This is more like use of default
values for RDF datasets in the query that allows invocation-time overriding.
This is somewhat similar to optional parameters with default values in PL/SQL
procedures and functions. However, I think (and as Newman suggested in his
reply e-mail) augmentation of RDF datasets should be considered too. |
|
minor
technical on 10.3 Constructing an output graph 2006-01-12T17:35:36Z
Fred Zemke The text
“ and a warning may be generated” has since been
removed in the new document version. |
|
minor
technical on 11.2.2 Effective boolean value 2006-01-12T17:38:09Z
Fred Zemke This behavior
is aligned with how this is done in XQuery and XPath. So, they are reluctant to change. |
|
minor
technical: A.7 grammar, rule [25] Constraint 2006-01-12T17:44:37Z
Fred Zemke According
to some members of the DAWG group this is a minor issue and they do not think
a change is needed. |
|
minor
technical: omissions from Appendix B Conformance 2006-01-12T17:45:22Z
Fred Zemke The DAWG
group does not want to put additional requirements for conformance regarding
error behaviors. Regarding extension, the current thought is that anything
more than SPARQL is not SPARQL. |