Re: To embed or combine

I think people got bogged down in the details and did not quite understand
the simple message that I was trying to send (in several short emails).

1. An embedding of RDF into RIF is necessary (or at least desirable), since
   a. It tells people how to exchange RDF through rif.
   b. Provides simple means of combining rif with rdf.

2. A model-theoretic semantics (in addition to 1) is redundant.
   After all this exchange Jos failed to convince (me at least)
   that it is of much use.

3. A model-theoretic semantics without 1 is practically useless, since this
   basically tells people to go and invent 1 on their own.
   (One needs some kind of embedding in order to make any sense out of
   rif anyway.)

So, my message is that the combined model theory is just
yet-another-thing-to-read-but-is-practically-useless.

We all can live with 1+2 in the document. The question is whether we want
to include stuff that is pretty much useless and makes the document more
complex.


	--michael  


> 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:20:25 UTC