Re: "entailment regime"?

Dave Reynolds <der@hplb.hpl.hp.com> writes:
> Sandro Hawke wrote:
> > (This message is likely to be controversial among the RDF folks, but I
> > think it's important.  It may also not be something we can agree on --
> > other Semantic Web working groups have been challenged by this -- but
> > let me at least try to make the case.)
> > 
> > In http://www.w3.org/2005/rules/wg/wiki/Arch/RDF, Jos writes:
> >> Furthermore, this data set has a particular entailment regime
> >> associated with it (e.g. simple, RDF, RDFS). 
> >>
> >> rif:rdfEntailmentRegime a rdf:Property ;
> >>     rdfs:domain rif:RuleSet ;
> >>     rdfs:range  rif:RDFEntailmentRegime .
> >     
> > If I understand this approach correctly, I'm afraid I have to disagree
> > with it.  RDF entailment regimes should *not* be specified.  It's a key
> > element of the architecture of the Semantic Web that semantics are
> > implied by the vocabulary in use, instead of being explicitely named.
> 
> Interesting. Where is this written down?

Sorry -- as I apologized to Bijan earlier, I shouldn't have made this
claim this way.  What I mean is that it's something that's key to how I
think the Semantic Web should work.  It's not in a W3C Recommendation or
anything.

> On the telecon we discussed that part of the proposal and I thought we 
> agreed to change it, that the entailmentRegime should be an attribute of 
> the ruleset rather than the dataset. At least that's what I was 
> suggesting and I thought Jos agreed and no one else objected.

Yeah, I didn't object because I couldn't figure out how to articulate my
concern.   I thought about it some more, and then sent the e-mail at the
start of this thread.

> Does that address your issue?

I don't think so.

> As discussed in the parallel thread with Jos and Axel I would prefer to 
> do that by providing an import mechanism rather than metadata. So that a 
> rule set where one wanted to process RDF data and assume RDFS semantics 
> could be something like:
> 
>     <rif:RuleSet>
>          <rif:import uri="http://www.w3.org/2007/rif#RDFSruleset.rif" />
>          ... rules ...
>     </rif:RuleSet>
> 
> However, if that were done indirectly via ruleset metadata that would be 
> OK too (I can make arguments both ways round if you like :-)).
> 
> If neither ruleset import nor ruleset metadata are acceptable to you 
> what's the alternative?

As I understand it, the semantics of an RDF file, like anything else
with a MIME type, should stand on their own.   To add additional
parameters affecting the interpretation is like saying "fetch
http://example.com/bar and interpret it as JPEG, no matter what MIME
type is received."   (That may actually be what you need to do some
times, but clearly one "SHOULD NOT" do that.)

I've been meaning to poke at that other thread -- let me do it by
suggesting the particular Web address at which we should publish rules
that implement RDFS: "http://www.w3.org/2000/01/rdf-schema".   That is,
we should provide, to the best of our ability, executable semantics for
RDFS. 

I'm hearing in that thread that it wont work, but I'm having trouble
understanding the difficulty.

> > This is for exactly the same reason I argued that RIF documents should
> > not be labeled with a dialect identifier, unless it's just a
> > suggestion/hint; it provides backward compatibility. 
> 
> I hadn't twigged that's what you were after. I think dialect metadata is 
> at least needed as a hint ("ah this rule set is supposed to be in 
> dialect D, I'm sure I had a D processor around here somewhere, I'll try 
> that one first").

I don't see how that's very helpful, since you need to handle the case
where you've never heard of D, but you have dialect E handy, and E is a
superset of D.  So implementations need a table of the dialects they
implement and the components implemented by each dialect.  When they get
a document, they determine the set of components in use and search their
table for a sufficient dialect.  That's not as easy as dispatching on
the dialect name, but it's not too hard.  *shrug* I guess there's no
harm in providing "D" so implementation can sometimes avoid the table
lookup -- I just worry that we'd get a lot of lazy implementations that
stopped there.  (Such implementation would work fine at first, so they
could sneak by -- and we'd only discover the problem when trying to
deploy new dialects -- suddenly we couldn't do it because of the user
base of non-table-dispatching implementations.)

> > The idea, though, is that you use all the entailment regimes which are
> > defined for the vocabulary in use.  So for an RDF/XML document that uses
> > no RDFS or OWL terms, RDF entailment applies.  If you use RDFS terms,
> > RDFS entailment applies.  If you use OWL terms, OWL entailment applies.
> > 
> > At a high enough level, this is equivalent to just using all the
> > entailment regimes you can.  I know for people concerned with
> > theoretical properties of logics, this is painful, and it does present
> > some challenges.  But if there's a case where this approach is a real
> > problem to users, I'd like to hear about it.
> 
> I don't think this is workable in practice. Applications need control 
> over which entailment regime to apply for many reasons. Consider writing 
> an OWL editor, my editor wants to treat the RDF making up the OWL as 
> plain triples when it is editing. Consider checkers such as Jena's 
> Eyeball, it proves useful to be able to check that all things used as 
> classes are defined as such, if you always had RDFS inference on you 
> couldn't do that. Consider applications wishing to make performance 
> trade-offs.
> 
> I can assure you that if in Jena we took away the ability to choose 
> inference level separately from content we would have major user support 
> problems.

I don't really understand this argument.   It sounds a bit like you're
arguing that program editors don't need to also execute the program
while it is being edited.   (Indeed, of course they don't.)  

Let's take, for example, and an RDF/XML file that matches the OWL-DL
syntax.  It's on the web, with Content-Type "application/rdf+xml".  We
can think of it as an RDF file, an RDFS file, an OWL-DL file, and an
OWL-Full file.  It is all of these.  There are lots of entailment
regimes one could use with it.  So, does it make sense to talk about
whether it is logically consistent, or whether it entails certain RDF
triples?   Be the current standards (as discussed at the start of [1]),
alas, no.

But let's try to keep aiming in the right direction; let's keep aiming
for option 1, so that the question of whether the file is RDF, RDFS,
etc, remains kind of silly -- it's all sort of the same language.

Back to RIF extensibility (as a bit of an analogy): the principle I
think we want is that when you can say something in multiple dialects,
it should come out the same in all of them (where practical).  So if you
want to say "A is a subclass of B", you can say that in RDFS, OWL-DL, or
OWL-Full.  And the document looks the same in all of these languages, so
looking at the document, I can't tell which one you used.  And that's
just fine as long as the document also means exactly the same things in
all of them.  It doesn't matter if you dispatch to your RDFS, OWL-DL, or
OWL-Full dialect handlers -- subclass means the same in all of them.

[ This is the point where someone -- Jos, perhaps? -- can jump in and
say that the semantics of RDFS and OWL-DL are dramatically different,
even on very simple files, so this could never work.  In terms of RIF's
extensibility mechanism, we might have the document above (just some
datalog rules) which is in both Dialect D (LP) and Dialect E (FOL), and
it *kind of* means the same thing, but in E there are also infinite
entailments! ]

> However, this last part seems like a more general semantic web 
> discussion that should be off the RIF list.

I'm not sure where else to have it.  I think it's connections to RIF are
pretty strong, really, both in RDF-compatibility and in understanding
what we want in extensibility.

      -- Sandro

[1] http://lists.w3.org/Archives/Public/public-rif-wg/2007Jul/0043

Received on Monday, 9 July 2007 02:00:13 UTC