Loading ...
Sorry, an error occurred while loading the content.

SquishQL Issue #3 : FROM : Specifying the source (fwd)

Expand Messages
  • Libby Miller
    background: Andy Seaborne and I have been thinking about improving the SquishQL syntax. Andy has an implementation which is looking rather more professional
    Message 1 of 2 , Sep 6, 2001
    • 0 Attachment
      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

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

      for those interested.

      libby

      ---------- 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

      Libby,

      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.

      (1) Simple

      FROM <URL>

      This leaves it to the implementations to decided on the typing policy. This
      is compatible with the composite URI scheme we discussed.

      (2) Advanced

      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
      implementation.

      Andy
    • Leigh Dodds
      [Seeing as there s traffic, I thought I might as well wade in :)] ... Just to let people know I ve been working with Inkling recently, to refactor some of the
      Message 2 of 2 , Sep 6, 2001
      • 0 Attachment
        [Seeing as there's traffic, I thought I might as well wade in :)]

        > Andy has an implementation which is looking rather more
        > professional than Inkling ;-)

        Just to let people know I've been working with Inkling recently,
        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:

        http://www.bath.ac.uk/~ccslrd/inkling/log.txt

        btw, I'm an SPO person, but thats probably because thats
        how I first starting thinking about triples.

        Cheers,

        L.
      Your message has been successfully submitted and would be delivered to recipients shortly.