Re: ACTION-420 Review of SW-compatibility

Jos de Bruijn wrote:
> 
>>>> 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

So: defining compatibility wrt. generalized RDF and then restricting it 
wrt. standard RDF is not an option?

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

they are not silly implementation wise. eg rdf stores store triples most 
efficiently using tables per predicates. since predicates are basically 
the *only* position where you are guaranteed to have only constrants, 
they are somehow special. blank nodes in pred-positions would mess this 
up big time. :-)

axel



> However, I do not feel that strongly.
> 
> 
> 
> Best, Jos
> 
>>
>> Axel
>>
> 


-- 
Dr. Axel Polleres
email: axel@polleres.net  url: http://www.polleres.net/

rdfs:Resource owl:differentFrom xsd:anyURI .

Received on Monday, 10 March 2008 19:59:28 UTC