Re: To embed or combine

Jos de Bruijn wrote:
>>>>> I'm afraid I don't really see the difference between "accessing RDF
>>>>> data" and "entailment regimes", so I don't really understand why they
>>>>> should be treated differently.
>>>> I'm not suggesting they be treated differently.
>>>>
>>>> To write rules that work with the data, or to implement a translator for
>>>> those rules, the data mapping does have to normatively defined. To me
>>>> this means that tr and the treatment of bNodes in data (not necessarily
>>>> queries), literals etc have to all be normative. In the current document
>>>> almost all of that is covered - literals are in the normative part, tr
>>>> is implicit in the model theory but the handling of bNodes is not
>>>> spelled out. Spelling tr out and defining the bNode handling in the
>>>> normative part would resolve this, and would further increase the
>>>> clarity of the document, at the trivial cost of moving a very small
>>>> number of lines of text around.
>>> I'm not sure what you mean with "spelling out tr". If you mean that we
>>> need to show how using RDF data with RIF rules can be done, then it is
>>> indeed something we still need to do, in the "Guide to using RIF with
>>> the semantic web" document you mentioned.
>> We want that too but simply defining tr in the normative part is also
>> simple and useful.
> 
> I'm not sure what it would buy us to define two semantics for the same
> thing.

?? I'm just suggesting that that the representation of the data be 
defined explicitly up front. The semantics is all about the entailments 
which can be defined model theoretically as you've done it. I don't see 
two semantics there.

>>> The handling of bNodes is indeed not spelled out, because it is implicit
>>> in the semantics.  They are symbols local to an RDF graph, so a
>>> combination does not need to, and should not, touch these symbols.  We
>>> do, however, need more explanatory text about this point.
>> No, we need to define the mapping so that builtins like isBlankLiteral
>> are implementable. It makes a difference whether they are represented by
>> undistinguisable URIs (your proposal) or by distinguisable URIs or by a
>> datatype (my proposal).
> 
> In my proposed combined model-theoretic semantics, blank nodes are not
> represented by anything in RIF, because they are local to RDF graphs,
> and can thus not be accessed outside of the graph it is contained in.
> In the proposed embedding which can be used to reduce reasoning with
> combinations to reasoning with RIF, blank nodes are Skolemized.
> So, the indistinguishable URI is not introduced for representation
> purposes, but only for reasoning purposes.
> 
> If blank nodes were to be represented by distinguished URIs, then they
> would no longer be blank nodes in the sense defined by the RDF semantics
> specification.
> 
> Thinking about it a bit more, I actually do not think a built-in like
> isBlanknode could be defined in a meaningful way while observing the
> semantics of blank nodes.

See SPARQL. The ability to detect blank nodes as part of a condition 
language is as useful in the RIF condition language as it was in the 
SPARQL query language - there is little difference between the condition 
part of a horn rule and query. I'm trying to ensure we are compatible 
with the existing standards here (a) because that's a good thing in 
itself and (b) because that feature is in there because it is used in 
practice.

> Some implementations may not observe the RDF semantics, and provide an
> implementation for the isBlanknode built-in based on an incorrect
> treatment of blank nodes, but I think we should observe the semantics
> defined in the W3C standard.

SPARQL is a W3C standard (well proposed standard).

>>>>> Wouldn't one simply use a combination with the simple entailment regime
>>>>> in this case?
>>>> Yes, I pointed this out in the "at first I was concerned" paragraph
>>>> (since subset semantics includes the trivial subset).
>>> I did not understand what is meant with "subset semantics".  Also, could
>>> you send a pointer for rho-df?
>> It's the ESWC-07 best paper that you yourself referenced. They called
>> their reduced RDFS {\rho}df did they not?
> 
> Ah, I did not recognize it without the latex markup :-)
> I'm still wondering what you mean with "subset semantics".

I've said before that in practice people don't always use or implement 
the full RDF or RDFS semantics but find subsets of it more convenient.
We agree that defining such convenient subsets (include syntactic 
subsets like \{rho}-df) is outside of RIF. Showing how you can support 
such community-agreed subsets as part of a guide document does however 
seem appropriate.

Dave
-- 
Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Tuesday, 11 September 2007 09:25:12 UTC