- From: Axel Polleres <axel.polleres@deri.org>
- Date: Wed, 19 Sep 2007 00:21:48 +0100
- To: Sandro Hawke <sandro@w3.org>
- CC: public-rif-wg@w3.org
Sandro Hawke wrote: > Axel Polleres <axel.polleres@deri.org> writes: > > >>>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/ >> >> > > > -- Dr. Axel Polleres email: axel@polleres.net url: http://www.polleres.net/
Received on Tuesday, 18 September 2007 23:22:24 UTC