W3C home > Mailing lists > Public > public-rif-wg@w3.org > March 2008

Re: ACTION-420 Review of SW-compatibility

From: Jos de Bruijn <debruijn@inf.unibz.it>
Date: Mon, 10 Mar 2008 19:48:22 +0100
Message-ID: <47D58276.4070607@inf.unibz.it>
To: axel@polleres.net
CC: RIF <public-rif-wg@w3.org>

>>> 11)
>>> As for the definition of extended RDF graphs.
>>> There are (for many implementers) good reasons, to keep literals and 
>>> blank nodes
>>> away from the predicate position.
>>> I am unsure about whether this liberal definition we use here is a 
>>> good idea, actually I would like to object against literals in pred 
>>> positions.
>> I do not really understand what your problem is with allowing literals 
>> in predicate positions in our extended notion of RDF graphs; what are 
>> these good reasons to keep literals and blank nodes away from 
>> predicate positions?
> a) It is not in RDF. We discussed in the F2F already that allowing more 
> liberal
> definitions than RDF is problematic maybe.

That would also be a reason to keep literals out of subject positions. 
So, I guess you are arguing for defining compatibility with respect to 
standard RDF?

> b) It is completely unclear to me what a blank node in a predicate 
> position shall mean.

Well, the RDF model theory gives a precise definition.
In short, like any other symbol, a blank node is mapped to an element in 
the domain.  Then, satisfaction of triples is determined by the 
extension function IEXT: IP -> 2^{IR x IR}.

>> The reason we consider extended RDF graphs is to accommodate possible 
>> extensions of RDF that are less restrictive in their syntax.
> So, can we define both a general framework plus one compatibility notion 
> actually compatible with current RDF? That would be fine with me.

The current notion is completely 100% compatible with standard RDF, 
since every standard RDF graph is a generalized RDF graphs, and the 
semantics is exactly the same.

I just see three options:
1 define compatibility only with respect to standard RDF
2-define compatibility with respect to generalized RDF
3- define compatibility with respect to "semi-generalized" RDF, in which 
you would not have literals and blank nodes in property positions

Option 3 does not make any sense to me, since I don't see any argument 
for disallowing literals and blank nodes in predicate positions when 
generalizing RDF.
Option 1 has the potential advantage that it might be easier to 
understand, because some people might not grasp the idea of generalized RDF.
Option 2 has the advantage that it can be used with an extended notion 
of RDF graphs; it can does accommodate certain possible future extensions.

As I stated earlier, it makes sense to me to consider generalized 
graphs, because the syntactical restrictions imposed by RDF on triples 
are rather silly.  However, I do not feel that strongly.

Best, Jos

> Axel


Jos de Bruijn,        http://www.debruijn.net/
One man that has a mind and knows it can
always beat ten men who haven't and don't.
   -- George Bernard Shaw

Received on Monday, 10 March 2008 18:48:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:49 UTC