Re: To embed or combine

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

I don't follow. I thought that the data would be represented in RDF.
The semantic correspondence defines how this data can be used in the RIF
rules.

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

It is unfortunate, as Bijan pointed out, that the SPARQL draft is at
odds with the RDF semantics standard when it defines the notion of query
answers.
However, this is technically not the case in the definition of the
isBlank "built-in".
In fact, isBlank is not a built-in in the way built-ins are used in
rules languages.  In fact, in SPARQL it is not part of the condition,
but of the (syntactic) filter; it checks to see whether there are blank
nodes in the query answer, and the filter defines whether the answer
should be retained in the answer set.

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

OK.

best, Jos

> 
> Dave

-- 
Jos de Bruijn            debruijn@inf.unibz.it
+390471016224         http://www.debruijn.net/
----------------------------------------------
The third-rate mind is only happy when it is
thinking with the majority. The second-rate
mind is only happy when it is thinking with
the minority. The first-rate mind is only
happy when it is thinking.
  - AA Milne