- From: Bijan Parsia <bparsia@cs.man.ac.uk>
- Date: Mon, 10 Mar 2008 19:29:45 +0000
- To: Jos de Bruijn <debruijn@inf.unibz.it>
- Cc: axel@polleres.net, RIF <public-rif-wg@w3.org>
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.
Cheers,
Bijan.
Received on Monday, 10 March 2008 19:27:56 UTC