SquishQL Issues List

Authors

Andy Seaborne <Andy_Seaborne@hplb.hpl.hp.com>
Libby Miller <libby.miller@bristol.ac.uk>

Last Modified

2001-09-18

Latest Version

http://ilrt.org/discovery/2001/07/squishql-issues/

Contents

0 name
1 uri-quote
2 triple-format
3 from-protocol
4 constraint-syntax
5 resultset-format
6 string-equals-operator
7 multiple-query-sources
8 quote-literals
9 tests
10 expression-functions-api
11 filter-extensions-api
12 potential-modules
13 bags-syntax
14 Reification: syntactic support?
15 anon nodes in queries
16 SELECT *

Issues

Issue Number Priority Description Status
0 High! Agree on a language name! resolved - "SquishQL"
1 1 URI quoting

see the thread Squissue: quote UIRs or not?

Proposal: Use N-Triple syntax: <uri>
for: makes it look like n-triple
against: embedding in xml
not resolved
2 1 Triple format: (S P O) or (P S O)? resolved S P O
3 1 "FROM protocol:" used to decide the query engine
Examples: "jena:", "sirpac:", "rdf:jdbc:postgress:"
see post to semantic web south west
resolved: (list of) uris; interpretation is implementation specific.
noted: What ever we decide about lists also will apply here (see issue about commas and uri quoting)
4   Constraint syntax: could we make it all triple-like?
"p(s, o)"? Prefix operators?
noted: there are other ways of doing this, but they don't seem to add anything here.
also noted: & or "and" may be used for multiple constraints. Keywords are case insensitive.
resolved keep as it is
5   ResultSet for results
Follow on: What we return graph-per-match?
propsosal: just bindings back;
not resolved - further discussion needed
6 1 String= operator.  What syntax?
Proposal: Use explicilty different operator: "eq".
numbers: > < = >= <=
strings: eq ne ge? gt? le? lt? like?
status: final list not resolved - further discussion needed.
7   Multiple sources for the query.
Is this the right way to do it? Or should there be a combined source, so the query is single source?
resolved: (list of) uris
noted: What ever we decide about lists also will apply here (see issue about commas and uri quoting)
8 1 Quote literals 
proposal: "" for literals
noted: depends on uri quoting, number quoting (currently none)
not resolved - depends on uri quoting
9 1?  Tests: datasets and queries.  Use JUnit Andy has tests, also Leigh Dodds
10 1? Expression functions API resolved: these should not be in the standard language
11 1? API for modules for filter extensions  resolved - no; see 10 - though very interesting idea
12   Some modules: string reg ex (use ORO?); URI operations? resolved - no; see 10
13   Bags: syntactic support? resolved - no, not in standard language
14   Reification: syntactic support? May help query engines over databases that hold reified statements implicitily. resolved - no not in standard language unless there's a proposal
15     SquishQL New issue: #15 : anon nodes in queries resolved
16     SquishQL New issue: #16 : SELECT * resolved yes