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

Nice idea David.
And I like that your example is about *consumption*, not production - I would hope that this exercise can use ease of consumption as the metric.

Your example of blank nodes is very important.
Another problem of blank nodes is that no-one else can make statements about the resource.
I won;t get into the discussion about whether blank nodes should be banned :-)
But this argument against their use leads me to a rule of thumb:

A string literal should only ever appear as the object of rdfs:label (or something that could naturally be made a sub-property of rdfs:label, such as foaf:name).

Hopefully the reason for this is clear:- if it is somewhere else, then it is essentially identifying a resource; and if it is a resource, someone else (or you, one day) may want to refer to it. And of course, if it is a string, you can't do that.
Yes, I know it is an extra URI (not blank, of course!) and a triple, but what is the point of RDF if you can't refer to resources?
I have to say that whenever I have been tempted to put a string in somewhere else I have been able to work out very real use cases where it would have been a bad thing to do.
Strings are labels, and that's it.

So what about other literals?
I actually wonder whether the same is often true here, but perhaps not as strongly. Should they only be used as the object of rdf:value or similar.
Consider if you have made a statement publishing your age using foaf:age. The age is an integer string.
This means that I can't make a comment on your age :-)
Or rather, if I do comment on your age, it will have to be more complex, and involve a URI for you.
So I can't for example say that your age is the same as my age (with some predicate).
And I can't give you a URI that is my age, that you could give to someone else who might know what it means, even though you don't.

I'm not sure if this is the sort of thing you were asking for, but that's my 2 cents worth.

Best
Hugh
On 12 Dec 2012, at 17: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?
> 
> 
> -- 
> David Booth, Ph.D.
> http://dbooth.org/
> 
> Opinions expressed herein are those of the author and do not necessarily
> reflect those of his employer.
> 
>

Received on Wednesday, 12 December 2012 18:11:05 UTC