SquishQL Issue #3 : FROM : Specifying the source (fwd)
- background: Andy Seaborne and I have been thinking about improving the
SquishQL syntax. Andy has an implementation which is looking rather more
professional than Inkling ;-)
we thought it might be a good idea to discuss some of the issues we have
on this list, to get some valuable input. We have an issues list at
for those interested.
---------- Forwarded message ----------
Date: Wed, 1 Aug 2001 20:29:26 +0100
From: "Seaborne, Andy" <Andy_Seaborne@...>
To: "Libby Miller (E-mail)" <Libby.Miller@...>
Subject: Issue #3 : FROM : Specifying the source
Previous we have talked about having a composite scheme for specifying the
data source. The issue is that we need to identify the source location, an
access protocol and the type of syntax for the model. Also, we need to
worry about quoting in the URI.
This leaves it to the implementations to decided on the typing policy. This
is compatible with the composite URI scheme we discussed.
Jena now has suppoprt for multiple readers (e.g. XML, n-triple) so
jena:file:c:/home/afs/data/x.rdf is not good enough. Is it n-triple or is
it XML? What flavour of XML? Basic syntax or abbreviated syntax (It does
not sniff the file to find out the difference between XML and n-triple). I
dare say this is not going to be a Jena-specific issue.
How about a general mechanism to describe the source: do it in RDF!!!
FROM (<location>, <lang>, "RDF/XML")
and leaving it up to the implementation environment to choose the technology
to process it (SiRPAC, Jena, a.n.other) and the language strings supported.
We need a base URI for the lang property. We could even allow multiple
triples : alternative sources, other properties etc. The exact meaning is
left to the implementation.
Overall, both these move naming the processing subsystem outside the scope
of the core language. Composite URIs (as we originally discussed) are still
legal but their interpretation is not specified by the language, only by the
- [Seeing as there's traffic, I thought I might as well wade in :)]
> Andy has an implementation which is looking rather moreJust to let people know I've been working with Inkling recently,
> professional than Inkling ;-)
to refactor some of the code and add JUnit test harnesses.
I've made some progress, mainly on the RDF package (RDFGraph, etc)
and hope to start in on the query stuff shortly.
I'm maintaining a work log at:
btw, I'm an SPO person, but thats probably because thats
how I first starting thinking about triples.