- From: Dave Reynolds <dave.e.reynolds@googlemail.com>
- Date: Tue, 19 Jan 2010 14:37:42 +0000
- To: Axel Polleres <axel.polleres@deri.org>
- CC: public-rif-wg@w3.org
On 19/01/2010 14:17, Axel Polleres wrote: > > On 19 Jan 2010, at 00:09, Axel Polleres wrote: > >> Hi all, >> >> I had some discussions about this very issue with sandro and chris at ISWC. >> This issue is also problematic for SPARQL, if we want to give a semantics to SPARQL over RDF+RIF >> since there is no way to define or link to a ruleset from a "normal" SPARQL datased. >> >> I suggest I will summarise the options in an email shortly and get involved when it is discussed in a telecon, apologies for my otherwise silence recently, being swamped with other issues. >> >> best, >> Axel > > > Dear all, > > this will come in two parts to make it easier to digest. > This first part is just a dump of options I discussed with Sandro and Chris over > lunch at ISWC (quite a while ago, I admit), > The second part will be a brief summary with one concrete proposal, following in a separate mail. > > So at ISWC we were talking about the problematic issue > that it is well possible to import RDF from RIF documents, but there is no way to - in > reverse - import RIF from RDF, which is something I'd really NEED, > e.g. in SPARQL, see my comment above. The original comment was about importing RDF into RIF, you are talking the about the reverse and I don't think any of this relates directly to the public comment. I, for one, don't understand the motivation of what you are trying to do here and so find it hard to comment on the options. What is the value if specifying import of RIF into RDF when we have no RDF representation of RIF? How would this help SPARQL? I would have thought what SPARQL needs is a notion of an entailment regime that can be specified by a RIF document. That seems rather different from importing a RIF document into an RDF graph. Dave > > Ideally, as it is possibly too late to get this in the official spec, we could at least publish > a WG note, maybe jointly with the SPARQL WG. > > I think there is a very simple "abstract" solution for this, using something similar to > owl:imports. For that, there seem to be two obvious Options, which I will > outline in the following: > > * Option 1: the following addition to the semantic conditions of models for > RIF-X-combinations: > > "The models of a RIF-X-model of a RIF-X-combination (G,R) > RIF-X-entailing the RDF graph > [ rif:imports R1] . > where R1 is an IRI referring to a RIF document are restricted to those models which are also > models of (G, R') where R' is identical to the RIF document R, with the > only addition that R' has additional imports clauses > Imports( R1 ) > Imports( G<http://www.w3.org/2007/rif-import-profile#Generic> ) > " > > I am a bit worried a bit here about the somewhat recursive nature of this > definition using "RIF-X-entailing the RDF graph > [ rif:imports R1] ." > ... so, here's a simpler Option: > > * Option 2: ... an alternative may be to view rif:imports > purely syntactical, i.e. require simply > that a triple " [ rif:imports R1] ." is explicitly mentioned in G)... it seems we'd > be safe with that in the sense that we'd follow the same "path" as OWL did with > their imports property: Note that particularly the RDF-based semantics of OWL > leaves out to take a clear definition of the semantics of owl:imports [1], and seems > to define the semantics of owl:imports on a purely syntactical level [2], I am not 100% sure here, though. > Particularly, it seems to me that [2] does NOT define e.g. what should be the behavior in case > someone writes a "weird" graph like. > > my:imports rdfs:subPropertyOf owl:imports. > <o1> my:imports<o2> . > > In that sense, it might be sufficient to similarly just say: > > "The models of a RIF-X-model of a RIF-X-combination (G,R) > where G contains a triple > [ rif:imports R1] . > where R1 is an IRI referring to a RIF document are restricted to > those models which are also models of (G, R') where R' is > identical to the RIF document R, with the only addition that R' > has an additional imports clauses > Imports( R1 ) > Imports (G<http://www.w3.org/2007/rif-import-profile#Generic>). > " > > The second Imports statement in both options, > Imports (G<http://www.w3.org/2007/rif-import-profile#Generic>). > intuitively re-importing the RDF graph G into R may seem to be redundant, but > but may be useful when a RIF processor capable of handling RIF-X-combinations > is only given an RDF graph with rif:imports clauses as input, to determine the single > highest profile to be used. Say, a RIF processor loads > the RDF graph G which could contain the statement > <G> rif:imports<R1>. > Then, single highest profile would simply be determined by the highest > profiles of the imported RDF graphs and ontologies in R1. > > > An alternative in both Option 1 an Option 2 to using > Imports (G<http://www.w3.org/2007/rif-import-profile#Generic>). > would be that we'd require rif:imports to specify the intended profile, e.g. > to require G to have some triples > [ rif:imports [ rdf:value<R1>; rif:imports-profile<importsprofile-URI> ]] > or - simpler just > R1 rif:usedWithProfile P . > and that would determine > Imports (G P). > instead. > > > Note that, we'd NOT cover recursive imports with that notion that go via owl:imports, in > neither Option 1 nor Option 2. I mean, e.g. that the behavior of > > G: > G owl:imports O1. > O1: > O1 rif:imports R1. > > would not really be covered, since that would need to alter the meaning of owl:imports, as > rif:imports properties do not form part of the importsClosure of an OWL document. > I think that's ok. We should not necessarily get to the idea to remedy this by > reusing owl:imports, as that seems to violate the domain and range restrictions > of owl:imports (unless we'd find agreement that it's ok that the "class of RIF > documents is a then implicitly a subclass of owl:Ontology). > > So, summarizing everything discussed in this mail, orthogonal to > Option 1 or 2 there would be several overall syntactic options > to write an import in RDF within a graph G, let's number them alphabetically, not to > confuse them with the orthogonal Option 1 an Option 2 mentioned so far: > > Option A: > [ rif:imports R1 ] . > ... generic profile, blank node. > Option B: > G rif:imports R1 . > ... generic profile, graph URI (might be inconvenient when the graph is merged) > Option C: > [ owl:imports R1 ] . > ... generic profile, blank node, somewhat "hijacking" owl:imports, with the consequences outlined above. > Option D: > G owl:imports R1 . > ... generic profile, graph URI, somewhat "hijacking" owl:imports, with the consequences outlined above. > Option E: > [ rif:imports [rdf:value R1; rif:profile P] ]. > ... specific profile using rdf:value, blank node, that admittedly looks awkward. > Option F: > G rif:imports [rdf:value R1; rif:profile P] . > ... specific profile using rdf:value, graph URI > Option G: > [ owl:imports [rdf:value R1; rif:profile P] ]. > ... specific profile using rdf:value, blank node, "hijacking" owl:imports > Option H: > G owl:imports [rdf:value R1; rif:profile P] . > ... specific profile using rdf:value, graph URI, "hijacking" owl:imports > Option I: > R1 rif:usedWithProfile P . > ... neat... > > My favorite is I, my worst choice is G, I guess... > > I think, if we can agree on a solution (there are several coin-flips in the proposals > summarized in this mail...) then it would be possible to publish this > - as an additional WG Note, > - as an informative section of http://www.w3.org/TR/rif-rdf-owl > - as a normative section of http://www.w3.org/TR/rif-rdf-owl > I guess it might be too late for the latter, the first one might sound simplest, but I am not sure whether a WG Note > could be reused by other Rec track specs, as I mentioned, this imports mechanism could be useful for SPARQL. > > That's all (probably too much at once...), > Axel > > 1. http://www.w3.org/TR/owl2-rdf-based-semantics/#Content_of_Ontologies_.28Informative.29 > 2. http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Imports >
Received on Tuesday, 19 January 2010 14:38:22 UTC