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

On 12 December 2012 18:01, David Booth <david@dbooth.org> 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.
>
> 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?  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 “( . . . )”?
> Etc.  What do others think?
>

Sounds like a good idea, in particular it could be useful for things like
canonicalization and signing.

I have pondered the blank node question for quite a long time and I think
it is a question of metaphysics.

Should we be able describe something without naming it?

I think the theoretical answer is probably yes.

It does make code that much trickier tho.

As a pragmatist you might say that making something simpler increases
adoption, and the advantage is a greater network effect.

Maybe the sem web needs to be split into intermediate, advanced, and expert
techniques ...


>
>
> --
> David Booth, Ph.D.
> http://dbooth.org/
>
> Opinions expressed herein are those of the author and do not necessarily
> reflect those of his employer.
>
>
>