Re: ACTION-420 Review of SW-compatibility

>>> 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
> 

-- 
                          debruijn@inf.unibz.it

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