RE: To embed or combine

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

Received on Tuesday, 11 September 2007 17:05:53 UTC