Re: Well Behaved RDF - Taming Blank Nodes, etc.

On 19 Dec 2012, at 16:42, Lee Feigenbaum <> wrote:

> On 12/19/2012 9:50 AM, Henry Story wrote:
>> On 12 Dec 2012, at 18:43, Pat Hayes <> wrote:
>>> On Dec 12, 2012, at 9:01 AM, David Booth wrote:
>>>> I'm writing a paper to propose a profile of RDF that would enable
>>>> simpler tools to process RDF, and I'm wondering if others have
>>>> suggestions of constraints that may be helpful to include.  The idea is
>>>> not to change the RDF standard, but to define a useful, voluntary subset
>>>> -- Well Behaved RDF -- that is sufficient for most RDF applications but
>>>> simplifies their development.
>>>> For example, one key limitation would be in the use of blank nodes,
>>>> which severely complicate what could otherwise be simple tasks, such as
>>>> comparing two RDF graphs for equality.  With unrestricted blank nodes,
>>>> this becomes a difficult graph isomorphism problem instead of a simple
>>>> text comparison.  Some have suggested eliminating blank nodes entirely,
>>>> but a more modest restriction would be to limit them to common idioms
>>>> that do not cause such complexity problems:
>>>> A Well-Behaved RDF graph is an RDF graph that can be serialized
>>>> as Turtle without the use of explicit blank node identifiers.
>>>> I.e., only blank nodes that are implicitly created by the
>>>> bracket "[ ... ]" or list "( ... )" notations are permitted.
>>> That is too restrictive. There is a real need to be able to describe things such as "Joe's father" or "a woman in a red dress" which are naturally phrased as bnodes with identifying descriptors attached to them.
>> Yes, but here for a HTTP related example:
>> The web creates such resources all the time: whenever you POST a form
>> and the server does not give you a URI for the returned result, you have in
>> fact created a resource that has not got a name. This resource will need to be
>> described using a blank node. It could be described well enough as a creation of
>> that form, and with date and time, but giving it a name on that server would be
>> an error, and forcing oneself to name a remote resource, when the remote owner
>> did not want to do that is more work than you may want.
> What's wrong with generating a UUID-based URI for a POST request?

There's nothing wrong per se. But it is more prone to a mistake happening
that having a blank node. The blank node is the easiest way to deal with
things that don't have names.

Here's another example: Imagine you have a rdf store and your URI index breaks.
You may have a bunch of things you can say about those URIs such as the
domain name and the protocol, but not the full path. There again it would be
easiest to describe this with blank nodes.

In any otherwise you end up with names that are just complicated blank nodes, and you
then have exactly the same problem as blank nodes, except you just end up growning and
growing your names as you go along.

But this is another http-range-14 like debate I think. I'd better not get involved....

> Lee
>>>> Are there other restrictions that would be helpful to have in a Well
>>>> Behaved RDF profile, which would simplify our lives as RDF developers,
>>>> but still meet the needs of most RDF applications?  For example, what if
>>>> anything might be said about non-lean RDF graphs? Should typed literals
>>>> be required to be well formed per their type semantics?
>>> FWIW, the RDF2 WG may well decide to make graphs with illformed literals inconsistent, which is equivalent to saying that the type semantics is imposed by the simple use of the literal.
>> I hope that does not make it impossible to create new literals.
>>>> Should the use
>>>> of rdf:first and rdf:rest be limited to well-formed, rdf:nil-terminated
>>>> lists, i.e., those that can be serialized as Turtle lists ( . . . )?
>>> That makes perfect sense. The 2004 specs suggest this, in fact: they permit applications to treat 'silly' list descriptions as errors.
>>> Pat
>>>> Etc.  What do others think?
>>>> -- 
>>>> David Booth, Ph.D.
>>>> Opinions expressed herein are those of the author and do not necessarily
>>>> reflect those of his employer.
>>> ------------------------------------------------------------
>>> IHMC                                     (850)434 8903 or (650)494 3973
>>> 40 South Alcaniz St.           (850)202 4416   office
>>> Pensacola                            (850)202 4440   fax
>>> FL 32502                              (850)291 0667   mobile
>> A short message from my sponsors: Vive la France!
>> Social Web Architect

A short message from my sponsors: Vive la France!
Social Web Architect

Received on Wednesday, 19 December 2012 15:47:49 UTC