Re: same-syntax extensions to RDF

Ouch.  Harsh e-mail, which I think is the result of a
misunderstanding.  I'll get to it in more detail in its context, but
the short version is that I never meant to indicate that I or "the
W3C" was strongly attached to a rule language being a same-syntax
extension to RDF.  It's something that could be very useful, however,
and it's worth coming up with a clear message on how feasible it is.

On with the message.

Thank you for the reference and details on the Montague result, and
its connection to KIF's formalisms.  In working out my next response
in this chain with Peter I was torn about whether to take the high
road and try for a real truth predicate which somehow worked in RDF or
the low road and pick something that merely works, without being very
powerful and tricky at all.  The Montague result confirms my suspicion
that the high road, while appealing from a distance, is impassible.
The low road, which involves essentially removing the second Montague
condition, still appears available.

But let's talk motivation and process first.

> If you want simplicity, surely a 'natural' syntax for FOL (or OWL, 
> for that matter) is simpler than any kind of RDF embedding? 

Simpler for some applications, certainly.  RDF was hatched as a
metadata format, however, and I'm concerned that some key metadata
applications wont work this way.  The semantic challenges of reference
loops come naturally with the web, whether or not we use RDF.  (This
point is discussed more in [5] and [6].)

> >I keep hearing about projects using RDF
> >encodings of Horn or FOL, and they turn out to have either unclear or
> >inconsistent semantics.  If we're going to move to a standard here, it
> >would help to clear up whether it is possible to do this kind of
> >encoding properly.
> 
> WHY? Why not get the standard done first, and then argue later about 
> how to do an RDF encoding? 

The two problems are closely related, and if both are to be addressed
in the next few years by the W3C, it should probably be by the same
WG. 

> Or, even more radically, why bother with 
> an RDF encoding?

That's the key motivational question here, yes.

I observe that some people seem to want an RDF encoding.  My goal in
this thread is to come up with a consensus message for them, such as
"Don't do that, because [list of convincing reasons]" or "Here's a way
to do it, which has certain [listed] difficulties, but works for
[listed application]."   

> Why do you have this RDF syntax bee in your bonnet? Dont get me
> wrong. Im all for RDF, and I like using it for all kinds of things
> that it can be naturally used for. But it does have its limitations.

Maybe people disagree about what's natural.

When working in LISP, Prolog, or most scripting languages, it's quite
natural to go between program code and program data, to eval data,
treating it as code.  In C or Java, or most compiled languages, it's
quite unnatural.

The first Montague condition is perhaps like offering eval; the second
is something much more ... weird.  Cool, but not necessary.  Something
like more like eval'ing an undefined string.

> >I can't imagine, for instance, that the approach
> >taken by SWRL 0.6 would ever be approved in a W3C Recommendation, for
> >the reasons I outlined in the team comment [1].
> 
> The semantic web can make its own standards without the W3C 
> imprimateur, if the W3C insists on being insane. But I think you are 
> wrong, in fact, since the W3C's own WGs are going to be producing 
> draft recs which don't satisfy these requirements.

Ooops!  Sorry!  I was not clear here.  I should not have made my
meaning depend on you following the link.  Arg.  

I meant "the approach TO LAYERING ON RDF taken by SWRL" is not
likely to ever be approved by the Consortium.

The linked text says:

      SWRL connects with RDF in two ways. The crucial connections is
      that RDF graphs can be directly expressed in SWRL (using only
      the obvious syntactic transformation) and they have exactly the
      same meaning. This allows SWRL rules to operate on and produce
      RDF data. It also allows a SWRL syntax to be used as an RDF
      syntax. 

      A second connection is presented in section 6 of the submission,
      an RDF syntax for SWRL. The goal here is to allow RDF systems
      which know nothing of SWRL to store and process it as if it were
      any other RDF data. Ideally, when authoring RDF content, someone
      could add a quick rule in SWRL, just as they can add little bits
      of OWL. 

      This second connection is technically challenging to specify
      fully and correctly. The submission warns that for the encoding
      in section 6 to be used, non-standard RDF semantics must be
      used. WE SUGGEST THAT REQUIRING NON-STANDARD SEMANTICS FOR A
      LANGUAGE IS LIKELY TO CAUSE A GREAT DEAL OF CONFUSION AND SOME
      MARKET FRAGMENTATION. We greatly hope the path forward for SWRL
      includes an RDF encoding with full and correct RDF semantics,
      and an eye towards real user applications. 

It was the here-capitalized part I was talking about.  I highly doubt
the W3C would Recommend a rule language which was layered on RDF but
only worked if you used non-standard RDF semantics.  I'm pretty sure
you'd object to such a Recommendation, as would I, unless there was
some amazingly good motivation.

It appears you thought I was saying W3C would never recommend
something which did NOT have an RDF syntax.  That helps explain the
vehement tone of your message.  Sorry again for the confusion!

It's hard for anyone to speak "for W3C"; the only real way to do it is
to put a statement out for the appropriate level of consensus gathering
and see whether consensus is achieved.  In this case, you may recall
the rule language working group charter draft I circulated last year
[4].  It said a layered-on-RDF syntax was one option the WG should
consider.  Since that charter was not put before the members (let
alone approved), it's not official, but I will note that no one said
that developing such a syntax should be manditory.

> You can get past the barrier by weakening the notion of reflection, 
> which breaks the second Montague condition. This is how the KIF 
> metatheory wriggled past the paradoxes, by putting a syntactic tweak 
> into the truth predicate so that it doesnt apply to some expressions. 
> But this is a tricky operation to get right. It works in KIF partly 
> because KIF does reification very transparently, using direct 
> quotation, so the syntax of the coded expression can be accessed 
> straightforwardly when stating the necessary constraint. This would 
> break if, for example, the language used an encoding mechanism that 
> allowed identity statements between encoded names (this is Peter's 
> observation). So if you were to do this for RDF somehow, the trick 
> might fail when you moved to OWL (because of owl:sameAs).

I'm not sure I see how, but I'm not sure if you're talking about the
KIF3 "true" predicate (from Don Perlis) or the KIF98 "wtr" simpler
non-looping predicate.  It sounds more like KIF98.  I don't think
Perlis' approach has the same problem.  But this is very close to
taking the high road, which I'm okay not even thinking about unless
some good motivation appears.

I just came across a rather nice :-) message in which I talked this
through in more detail [5], and a nice followup from Daniel Mahler
[6].   The thread died there, though, I guess.

> >Meanwhile, it is "obvious" how to write them informally and with
> >subtle errors.
> 
> It SEEMS obvious, but appearances are misleading. It seemed obvious 
> to Frege, until Russell pointed out the problem.

Right.  That's why I put the word "obvious" in quotes.  The fact that
it seems obvious is a problem, because it means people will keep
trying to do it, and may even formally object to a WG trying not to do
it, unless we can clearly explain why it's a bad idea.  Quoting
Montague at them is probably part of that explanation, but only part.

> Why do you want to be able to push all SWeb languages through an RDF 
> pipeline? 

While I've disavowed this being a requirement, yes, I do still think
this would be useful.   I'll answer in that spirit.

Basically for the same reason I want to push all the other data in the
world through an RDF pipeline.  The good things about putting data in
RDF -- using ontologies to express common ground, using URIs for
extensibility, data fusion for free, uniform chunks to point at in
metadata, being able to write simple and complete fast data stores
(triplestore), having a simple query language -- would all be kind of
nice to have for applying to rules, too.  In the database programming
world, people often find it useful to put bits of database code into
the database.  This is like having "eval" -- it's a nice trick, and
people will generally use it if it's available, but it can also get
messy, and is frowned upon in some circles.

Many of the above advantages also apply to XML, of course.  As I say,
this isn't a requirement, but I suspect it would be a nice feature.
And it's something people will surely do anyway, unless there's a
clearly stated reason against it.

It SEEMS to me that my "uncle" use case can be addressed, without a
problem, by simply removing the second Montegue condition. But I'm
going to post this in the hopes of clearing up the misunderstanding
now, and work through the low-road details separately.

      -- sandro


> >[1] http://www.w3.org/Submission/2004/03/Comment (in the "RDF" section)
> >[2] http://www.w3.org/TR/rdf-mt/
> >[3] http://lists.w3.org/Archives/Public/www-rdf-logic/2004Dec/0022.html
[4] http://lists.w3.org/Archives/Public/www-rdf-rules/2003Nov/0028.html
    See section 2.3 (list item 1)
[5] http://lists.w3.org/Archives/Public/www-rdf-logic/2002Sep/0013.html
[6] http://lists.w3.org/Archives/Public/www-rdf-logic/2002Sep/0015.html

Received on Thursday, 30 December 2004 16:03:56 UTC