Re: Queries and report generation in RDF/N3

At 01:54 AM 4/26/02 +0100, Sean B. Palmer wrote:
>That aside, I'm hoping that this parser will be swift and portable.
>However, I tried it on some real-world N3 data [1], and got some odd
>errors:-

>the data is valid, and CWM parses it just fine. Could you possibly check
>this out for me? It seems as if it just doesn't allow the ":" prefix, which
>is odd.
>
>[1] http://infomesh.net/2001/12/map/data.n3

I've fixed the directive errors, but that data raises a question about N3 
syntax:

Consider:

    x:ANB a:icao "KANB";

and also:

    x:ANB a:icao .

I would have thought the latter is syntactically valid N3, but cwm thinks 
not.  But this is:

    x:ANB a :icao .

So it appears that the disambiguation of 'a' as a prefix and 'a' meaning 
rdf:type is based on whether it is immediately followed by a space.  Does 
this seem right?

I've updated my parser so that a name followed immediately by a colon is a 
distinct lexical entity, and fixed a number of other bugs.  Your file [1] 
now parses without errors.

Thanks again for the test data.  It's now part of my (limited) test suite.

I've also started porting this code to Jython (with a view to front-ending 
a Jena RDB Model).  The N3 parser works OK, but I'm having some troubles 
with some of the file support routines -- os.access() not supported.  Are 
there any other easy ways you'd recommend, using Python to (a) check that a 
file exists and is readable, and (b) that a directory exists and is writeable?

The software at [2] is updated with the fixes.

BTW, for ease of testing the programs N3SyntaxCheck.py and 
N3GenMsgRegistry.py default to using some standard files if no command line 
arguments are supplied -- that logic (i.e. "if not argv or len(argv) <= 1: 
...") should probably be removed if these are used in different environments.

#g

[1] http://infomesh.net/2001/12/map/data.n3

[2] http://www.ninebynine.org/Software/N3ReportGenerator.zip


-------------------
Graham Klyne
<GK@NineByNine.org>

Received on Monday, 29 April 2002 05:06:56 UTC