Notation 3 support

[David Booth]

Hi all,

First of all, thanks to all of you for the great work you have done on
these packages!  I have not been using them (yet) but I have been
passively following their development with some interest.  One
suggestion below . . . .

On Mon, 2010-07-05 at 10:07 -0400, Gregory Williams wrote:
> On Jul 4, 2010, at 5:18 PM, Toby Inkster wrote:
[ . . . ]
> > In the mean time, here's a Turtle serialisation bugette I've discovered.
> > Create an RDF graph along these lines:
> > 
> > 	_:foo <#a> <#b> .
> > 	<#c> _:foo <#d> .
> > 
> > It will be serialised something like this:
> > 
> > 	[] <#a> <#b> .
> > 	<#c> _:r1234567890 <#d> .
> > 
> > Putting aside the fact that the second triple shouldn't be serialised
> > in Turtle at all, as it's not legal RDF, the serialiser has lost the
> > connection between the two appearances of the blank node.
> > 
> > I imagine when it decides to use '[]' rather than '_:something' to
> > serialise a blank node, it first checks whether the node is the object
> > of any triples - it doesn't check whether it's the predicate.
> 
> Yes, this is exactly why it won't serialize properly.
> 
> > There's a slightly bigger option of what to do when a serialiser tries
> > to serialise a triple that cannot legally be represented in the format
> > its outputting. I'd suggest there should be a constructor option along
> > the lines of:
> > 
> > 	$s = RDF::Trine::Serializer->new('turtle', illegals=>'die');
> > 
> > Where 'illegals' can be set to 'die', 'warn', 'skip' or 'force'. If
> > 'die' the serializer just dies when serialising something illegal; if
> > 'warn' it issues a warning to STDERR and then skips the triple; if
> > 'skip' it silently skips the triple; if 'force' it attempts to
> > serialise the triple even if it means that the output is not strictly
> > valid.

One other option to consider: in some cases it may be possible to
serialize a conforming 'workaround' that would have the same (or similar
enough) semantics as the original.  For example:

1. Instead of 

      "hello"^^xsd:String :foo :bar .

serialize

      _:lit0 :foo :bar .
      _:lit0 owl:sameAs "hello"^^xsd:string .

or, if the serializer happens to know

      :foo owl:inverseOf :fooInverse .

then it might serialize the above as

      :bar :fooInverse "hello"^^xsd:string .

2. Instead of:

      <#c> _:foo <#d> .

skolomize the bnode (i.e., make up a globally unique URI for it) and
serialize:

      @prefix bnode: <http://UNIQUE_NAMESPACE/foo> .
      <#c> bnode:foo

where "UNIQUE_NAMESPACE" would be some kind of unique namespace path.
There are several ways to generate one, such as generating a GUID in a
namespace that you own.  We don't yet have convergence on conventions
for doing this, but hopefully that will come over time.

Off the top of my head I don't know if all cases of non-serializable
statements could be handled with workarounds like this.  

Thanks!


-- 
David Booth, Ph.D.
Cleveland Clinic (contractor)
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.