Re: ACTION-420 Review of SW-compatibility

Bijan Parsia wrote:
> On 10 Mar 2008, at 18:48, 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}.
> 
> Interesting...this suggests that blank nodes are not treated as 
> variables (but as constants)?
> 
> (I ask because this is in heavy debate in the OWL WG...if RIF is going 
> to be playing with RDF (e.g., generalizing it) it's probably important, 
> or at least helpful, to coordinate.
> 
>>>> 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
> [snip]
> 
> 3 is akin to what sparql allows, yes? I guess that provides *some* reason.

SPARQL only allows this for graph patterns AFAIR, not for example for 
constructed triples in the CONSTRUCT parts. So, since triples in 
patterns having literals in subject positions cannot match any triple in 
standard RDF graphs anyway, and the semantics of COSNTRUCTs is 
compatible to standard RDF...  this loosining of the original RDF 
restrictions in SPARQL is somewhat redundant ... and does not extend 
standard RDF. Here though, it seems we do propose to extend standard RDF.

best,

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 20:05:31 UTC