Re: example of asn07 as OWL subset, musings on RDF/XML

The potential problems Axel pointed out are similar to the problems the
OWL working group ran into when defining the same-syntax semantic
extension of RDF.  Their biggest problem was that they could not go
beyond the syntax of RDF, so they had to encode OWL constructs as RDF
triples, and give a semantics directly to these triples.

We would run into similar problems if we were also to define a
same-syntax extension semantic extension of RDF.  However, I believe
that we decided some time ago that we would not do so.


There are several reasons why one would want to exchange RIF rules using
RDF.  RIF rules can be seen as data, and RDF is *the* data language for
the semantic Web; representation of RIF rules as RDF would allow, for
example, the use of existing semantic Web tools for storage and
retrieval of RIF rules (I have already heard from several people in the
semantic Web community that they want to do exactly this). RDF also
provides a flexible means of linking RIF rules with other resources
(e.g. via annotations), and vice versa.

Creating an RDF serialization of RIF is not hard, as pointed out by Sandro.
Axel pointed out that such a serialization might raise questions about
the semantics, especially when considering combinations with RDF (this
is independent from the semantics given for such combinations, whether
it is operational or model-theoretic). I would indeed see issues here if
we were to consider RIF as a same-syntax extension of RDF. However,
since it is not such an extension, we do not necessarily run into any
problems.

Here is how I think an RDF syntax for RIF could be defined (this is
similar to how the RDF syntax for OWL DL is defined):
- An injective mapping r from RIF rules and conditions  (in the abstract
 syntax) to RDF graphs is defined.
- An RDF graph S is the RDF representation of an RIF rule set or
condition P iff S=r(P).

So, the semantics is not defined on the RDF-syntax level, but only on
the abstract syntax level, hence nothing is changed in the definition of
RIF.
This means, among other things, that when merging the RDF representation
of an RIF rule set with some arbitrary RDF graphs, chances are the
resulting RDF graph is not the representation of any RIF rule set. So,
the combination of an RIF rule set and an RDF graph cannot be
represented as one merged RDF graph.

The latter shows the probably biggest drawback of using RDF for the
exchange of RIF rules: there is a certain disconnect between
a- the RDF data which represents the RIF rule set and
b- the RDF data which is used by the RIF rule set.


Just my 2 cents.


Best, Jos



>>>> So, I think it's clear that a RIF document *can* be transmitted in
>>>> RDF/XML.  The data model of the syntax is compatible with the RDF data
>>>> model (which isn't surprising, since at this level of details it's a
>>>> generic object model).  And if we make a non-RDF/XML syntax, we can
>>>> define a GRDDL transform to RDF/XML, so the semantic issues the same.
>>>
>>> Well, not quite. I mean, any XMl can be transformed to RDF by the GRDDL
>>> detour, but I'd not expect GRDDL transforms are to be dealt with
>>> natively (at the semantic level) in RIF), whereas we seem to intend to
>>> do so with RDF. I just wondered what RIF/RDF *means* in RIF if RDF
>>> itself has a meaning in RIF by the discussed embedding/model theory
>>> combination...
>>>
>>> If we say that RIF documents have a meaning in terms of RDF and RDF
>>> graphs have a meaning in terms of RDF vice versa, then I am somewhat
>>> afraid that we  run IMO into something strange (which was what I was
>>> trying to ask at the end of the phone conf today...)
>>>
>>> 1) Take an RDF graph
>>>
>>> s p o .
>>>
>>> 2) In RIF this means:
>>>
>>> Forall s[p->o].
>>>
>>> 3) This is in "RIF/RDF" something like (I assume here the RDF reading
>>> of =
>>>
>>> the RDF/XML):
>>>
>>> _:f a Forall.
>>> _:f rif:formula _:f1.
>>> _:f1 a Frame.
>>> _:f1 rif:oid s.
>>> s a rif:Const.
>>> _:f1 rif:slot _:s.
>>> _:s rif:slotTerm p.
>>> p a rif:Const.
>>> _:s rif:slotValue o.
>>> o a rif:Const.
>>>
>>> (I had to invent new properties here for the slotTerm  and slotValue,=20
>>> BTW, because I wouldn't know how to otherwise tweak the term-value
>>> pair=20
>>> into RDF)
>>
>>
>> So far, so good.  What you've done here is taken an RDF triple,
>> translated it into a BLD expression, and then shown us RDF triples which
>> fully describe that BLD expression.
>>
>>> From an RDF perspective, the triple in step 1 says that <s> has a
>> property <p> which has value <o>.  The RIF statement in step 2 says the
>> same thing.  The RDF statements in step 3 say that the RIF statement in
>> step 2 exists.   And if you want to construct a description of the
>> step-3 statements, you can, but nothing compels you to.
>>
>>
>>> 4) Now, this in turn again is to be interpreted in RIF as:
>> "is to be interpreted"?  This is where you lose me.  I don't see
>> anything automatic here.  
> 
> If we have a combined model theory, then wouldn't anything which
> has a "meaning" in RDF also automatically carry the respective RIF
> meaning and vice versa and so forth? Well, maybe you are right and this
> is not really a major problem, but even then:
> 
>  My idea was rather that if we thereby (by introducing an RDF syntax)
> have embeddings in both directions these should be idempotent for simple
> RDF data, if possible.
> 
> At least for UC10
> (http://www.w3.org/2005/rules/wg/wiki/UC10_Worked_Example) where the
> aim is to seemlessly combine Rules with RDF Data, I would like to have
> that feature. However, that wouldn't fit with the idea so far, to just
> "read" a striped XML syntax as RDF.
> 
> My point is: which RDF is implied from the "RIF reading of RDF"
> step 1) or step 3)? (or even steps 5)7)9) ...? )
> 
> I think an RDF syntax which keeps in mind requirement 1) below
> would keep matters cleaner. Requirement 1) meaning that
> the RIF reading of a triple s p o. fact s[p->o]. should simply be (s p
> o.) Would that be achievable? Does it make sense to you?
> 
> ===============================================================
> 1) s p o. (in RDF) =3D  s p o. (in RIF/RDF)
>   ie. no difference for pure data/or facts.
> 
> 2) I would't bloat up slots (occurring in rule heads or bodies) to=20
> anything more than triple(-patterns) with possibly variables.
> 
> 3) It should be guaranteed that the RDF version of a ruleset r=20
> (RDF-)merged with some RDF graph g should not possibly change the=20
> RIF-meaning of the *single rules* in r. ie, it should be allowed to=20
> merge rulesets, rulesets and data, but not data into rules by simply=20
> merging the representing RDF graphs.
> ===============================================================
> 
> FWIW, I think that we should get clear about all implied issues and
> possible desiderata of an RDF syntax and strive for a more hybrid RDF
> syntax in maybe a second step than just tweaking the more or less stable
> XML syntax into RDF now. As said in my last mail already, I do not
> oppose the idea of an RDF syntax per se, but I doubt whether just
> wrapping an <rdf> tag around the XML gives us something useful. Could we
> agree upon that and start off there?
> 
> best,
> Axel
> 
>> I don't think the step-1 triple entails the step-3 triples; not in any
>> logic we need to worry about.
>>
>> This is why it seems the same as with GRDDL.   There are tranformations
>> you can make, but they are not entailments in a logic, they just go from
>> one graph to a different graph.
>>
>> Thoughts?
>>
>>      -- Sandro
>>
>>
>>> Forall Exist _:f _:f1 _:s
>>>  AND( _:r[rdf:type -> rif:Ruleset].
>>>       _:r[rif:formula -> _:f].
>>>       ...
>>>     )
>>>
>>> BTW: the blank nodes as existentials is probably not right here,
>>> since=20
>>> it is in the head, I should have skolemized, therefore
>>>
>>> Forall
>>>  AND( sk:r[rdf:type -> rif:Ruleset].
>>>       sk:r[rif:formula -> sk:f].
>>>       ...
>>>     )
>>>
>>> 5) Now this in turn in RIF/RDF "means"
>>>
>>> _:f a Forall.
>>> _:f rif:formula _:f1.
>>> _:f1 a Frame.
>>>
>>>
>>> 6) proceed analogous as in 4) ... running into kind of an endless
>>> blowup =
>>>
>>> of reifications, if you want.
>>>
>>> This can be played on until infinity... I think, if we want something=20
>>> RDF "readable" we should then have something "hybrid" which leaves
>>> RDF data as RDF data, if possible, and only adds RDF annotations for=20
>>> rules as necessary (which could be implicit, sure).
>>>
>>> I am not sure at the moment, how such a hybrid syntax could look
>>> like,=20
>>> but would ... rather than the above, envision some minimal
>>> requirements=20
>>> I would like in a RIF/RDF syntax:
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>>>
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>>>
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> 1) s p o. (in RDF) =3D  s p o. (in RIF/RDF)
>>>  ie. no difference for pure data/or facts.
>>>
>>> 2) I would't bloat up slots (occurring in rule heads or bodies) to=20
>>> anything more than triple(-patterns) with possibly variables.
>>>
>>> 3) It should be guaranteed that the RDF version of a ruleset r=20
>>> (RDF-)merged with some RDF graph g should not possibly change the=20
>>> RIF-meaning of the *single rules* in r. ie, it should be allowed to=20
>>> merge rulesets, rulesets and data, but not data into rules by simply=20
>>> merging the representing RDF graphs.
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>>>
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>>>
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>
>>> I am not 100% sure about 2), but interestingly, 2) in my view rather=20
>>> cries for viewing RIF syntax rather as an *extension* of RDF(syntax)=20
>>> than an embedding RIF itself *into* RDF syntax... (just like XML is=20
>>> embeddable in RDF in the form of XML literal values). LEet me give an=20
>>> example of another spec which follow similar thoughts, it seems:
>>>
>>> SPARQL: Remarkably, SPARQL's syntax *does* build upon a very successful
>>> (because easily human as well as machine readable) syntax: Turtle.
>>> I don't see any intention in SPARQL to define an RDF syntax for
>>> SPARQL=20
>>> itself. Even thinking about an XML syntax for SPARQL was postponed so=20
>>> far. Also, the result format (except for CONSTRUCT queries) is XML -
>>> and =
>>>
>>> not RDF. All that for a language which is to be a core Semantic Web=20
>>> language!
>>>
>>> This is not meant as opposing a RIF/RDF syntax per se, and the SPARQL=20
>>> analogy merely came to my mind because I was doing some research
>>> about=20
>>> SPARQL (and the possible usage of SPARQL itself as a rules language)=20
>>> recently [2].
>>>  Anyway, this is meant to start a deeper discussion about what an=20
>>> RIF/RDF syntax shall achieve and why do we want/need it and what are
>>> the =
>>>
>>> implications. You might well completely disagree with my minimal=20
>>> requirements outlined above...
>>>
>>> best regards,
>>> Axel
>>>
>>> [2] Axel Polleres, Fran=E7ois Scharffe, and Roman Schindlauer.
>>> SPARQL++=20
>>> for mapping between RDF vocabularies. In Proceedings of the 6th=20
>>> International Conference on Ontologies, DataBases, and Applications
>>> of=20
>>> Semantics (ODBASE 2007), Vilamoura, Algarve, Portugal, November 2007.
>>> To =
>>>
>>> appear. http://www.polleres.net/publications/poll-etal-2007.pdf
>>>
>>>
>>> 1. Axel Polleres, Fran=E7ois Scharffe, and Roman Schindlauer.
>>> SPARQL++ fo=
>>> r=20
>>> mapping between RDF vocabularies. In Proceedings of the 6th=20
>>> International Conference on Ontologies, DataBases, and Applications
>>> of=20
>>> Semantics (ODBASE 2007), Vilamoura, Algarve, Portugal, November 2007.
>>> To =
>>>
>>> appear. http://www.polleres.net/publications/poll-etal-2007.pdf
>>>
>>>
>>>> The question is just whether the *primary* *normative* syntax is a
>>>> subset of RDF/XML or is some other essentially-equivalent XML syntax.
>>>> =20
>>>>> From my perspective, it seems easier to just talk about transforms on
>>>> the semantic-level data -- that is, the object model -- not on the XML
>>>> form.
>>>> =20
>>>>     -- Sandro
>>>> =20
>>>> =20
>>>
>>>
>>> --=20
>>> Dr. Axel Polleres
>>> email: axel@polleres.net  url: http://www.polleres.net/
>>>
>>>
>>
>>
>>
> 
> 

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