Re: Toward easier RDF: a proposal

On 11/21/2018 5:40 PM, David Booth wrote:
> 6. Standardized n-ary relations (and property graphs).  Since
> RDF natively supports only binary relations, relations between
> more than two entities must be encoded using groups of triples.
> A W3C Working Group Note[9] describes some common patterns,
> but no standard has been defined for them. ...
> 
> This deficiency has greater significance than it may appear,
> because it is subtly related to the blank node problem:
> a major use of blank nodes is to encode n-ary relations.
> In other words, n-ary relations are a major contributor to
> the blank node problem.

Note that there is an almost exact analogy to relational tables that do 
not have primary keys.  The essence of the thing is that there are two 
ways to know the identity of something: one by its id and the other by 
the collection of its attributes.  In database practice, tables without 
ID columns are practical only for relatively simple databases use cases; 
they do not allow for foreign keys.  This is precisely the same 
situation as what David is describing.

In database practice, the problem is usually solved by adding a primary 
id column, even if those ids are arbitrary and only unique within a 
database or even just a table.  For RDF, of course, adding globally 
unique ids would be quite a burden.  I could imagine a IRI scheme 
specific to blank nodes;  maybe that would be useful (it might be 
valuable to know that a particular id had been derived rather than given 
by the original graph): "blank://example.com/ABEC-2BD-34AEABC" or some 
such. A SPARKLE processor, for example, could create such an id and 
attach it to a blank node in the result graph in some useful way.

> Furthermore, standardized n-ary relations could also enable
> direct support for property graphs[10], which have emerged as
> a popular and convenient way to represent graph data

Topic maps natively support n-ary relationships.  The topic map n-ary 
relationship could obviously be modeled in RDF, and this might be a 
useful idiom.  But a topic map relationship requires an id too, so this 
approach doesn't get around the blank node id problem.

It seems to me that the problem of blank nodes is that there seems to be 
no general way to assign them ids in a reproducible way.  If the graph 
could be serialized an a canonical fashion, id's could be assigned 
uniquely in serial order.  But without ids for the blank nodes, or if 
the graph were to change, we can't do the serialization so that blank 
node ids could be assigned.  A Catch-22 situation!

Received on Thursday, 22 November 2018 00:00:03 UTC