Re: To embed or combine

For most use cases the approaches are interchangeable, because the
embedding actually consists of algorithms for checking satisfiability
and entailment according to the model-theoretic semantics.
The entailments which can be computed through the embedding are the same
as which hold according to the model-theoretic semantics. This is
analogous to a forward-chaining algorithm which computes the minimal
Herbrand model, and hence all entailments, of a set of Datalog rules.

So, assuming we are only interested in entailment, the choice boils down
to (a) definition style, i.e. operational versus model-theoretic
semantics, and (b) compliance with the W3C RDF semantics standard; the
model-theoretic semantics for combinations builds on the standard
notions defined in the RDF semantics document, whereas the operational
semantics does not.

Best, Jos

Paul Vincent wrote:
> As Chris was threatening a poll on this topic, would it be possible to
> get a sample use case or 2 as to how this question impacts RIF?
> 
> Judging from the debate, it seems this must be more important than it
> seems (eg building in a RDF dependency for a RIF dialect used only for
> rule languages manipulating RDF?).
> 
> Is there any example (eg using RIF for rule system R ruleset RS solving
> problem P makes embedding RIF much more sensible, or a situation where
> RDF evolves such that a dependency in RIF is not useful) which
> demonstrates why either of these 2 approaches is better?
> 
> If there is no simple use case I suspect I will have to abstain in any
> vote.
> 
> Paul Vincent
> TIBCO | ETG/Business Rules 
>  
>> -----Original Message-----
>> From: public-rif-wg-request@w3.org
> [mailto:public-rif-wg-request@w3.org]
>> On Behalf Of Jos de Bruijn
>> Sent: 11 September 2007 11:08
>> To: Dave Reynolds
>> Cc: Public-Rif-Wg (E-mail)
>> Subject: 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

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