Notation 3 support

[Toby Inkster]

On Fri, 2 Jul 2010 15:28:54 -0400
Gregory Williams <greg at evilfunhouse.com> wrote:

> I think this is all very cool (even though I have never really had a
> need or desire to venture far into the N3 space). In general I'd
> prefer this to be a separate package for two reasons. The first is
> that at some point I assume somebody is going to want things like
> property paths and the rule evaluation mechanisms to deal with
> log:implies, and those are things I think belong at a higher level
> than what RDF::Trine is trying to do (though it would be a shame if
> we can't find some shared code to use between N3 and SPARQL 1.1
> property paths).

N3 Rules I don't plan on implementing; or if I were to, that would be
something separate - on the same sort of level that an OWL or RIF
implementation would be.

Right now I just think it would be nice to be able to send arbitrary
Notation 3 to a parser and get something back. Right now, you can use
the Turtle parser in an eval{} block and get everything up to the first
non-Turtle-ism, but something more reliable would be good.

Property paths are definitely needed for this. N3 property paths are
not the same as in SPARQL - they're a simpler thing that only need to
be dealt with in the parser; not the model.

e.g. (note the single '^', not double)

	<SomeDocument> foaf:maker "Toby Inkster"^foaf:name .

Uses a property path, but property paths are just shorthands for
bnodes. The same data can be expressed as:

	<SomeDocument> foaf:maker [ foaf:name "Toby Inkster" ] .

> Also, having a separate package would simplify the process of
> updating/fixing the N3-specific stuff without having to tie it to an
> RDF::Trine release.
> 
> I'm happy to continue to add hooks in RDF::Trine::Node::Literal to
> make this sort of stuff possible, but I'd like to think some about
> how to generalize the extension mechanism so that things like
> Kjetil's ::Node::Literal::XML and your ::Node::Formula are possible
> without hard-coding support for each extension in the Literal class.

Yep, keeping it separate is probably my preferred solution. This would
need some kind of hook in RDF::Trine::Node::Literal. Something similar
to how parsers indicate the media types they can handle would be
adequate.

By the way, the Notation 3 parser is a subclass of the Turtle parser.
It overrides tonnes of its parent class' private methods. How safe is
this? Are the internals of the Turtle parser likely to change much?

-- 
Toby A Inkster
<mailto:mail at tobyinkster.co.uk>
<http://tobyinkster.co.uk>