W3C home > Mailing lists > Public > www-rdf-rules@w3.org > October 2001

Re: Where is the SW going? (was Re: Expressiveness of RDF as Rule Conclusion Language (was Re: What is an RDF Query? ))

From: Graham Klyne <GK@NineByNine.org>
Date: Tue, 16 Oct 2001 13:14:36 +0100
Message-Id: <>
To: Pat Hayes <phayes@ai.uwf.edu>
Cc: Dan Brickley <danbri@w3.org>, <www-rdf-rules@w3.org>, <em@w3.org>
At 03:02 PM 10/15/01 -0500, Pat Hayes wrote:
>>We still call it RDF.
>I don't!  And this is absolutely central. If the RDF specs don't specify a 
>meaning, then that meaning is NOT in RDF. That's what 'being in RDF' 
>means. Now, a particular piece of RDF might in some broader sense 'have' 
>some meaning that is invisible to an RDF processor - ie something that 
>interprets RDF graphs according to their RDF-model-theory meanings and 
>draws RDF-valid conclusions from them, say -  but it is very important not 
>to say that this meaning in 'in RDF', because in the only sense of meaning 
>being 'in' a language *that is available to a mechanical process*, it 
>isn't. At best you might say that it is RDF-encrypted, or something; its 
>there, but completely hidden from the RDF layer.

What terminology can we use for a program that is written using (say) the 
programming language C, and also makes use of well-known 3rd party 
libraries of functions?  Many folks would say it's written "in" C, even 
though the complete meaning of the program is not defined by the C 
programming language.

 From a formalist's point of view, I take your point that C+libraries is 
not the same as the C language.  But this use of libraries is something 
that happens commonly in practice, and I think it would be most useful to 
have a way of (and terminology for) dealing with this.


When Dan said:
>>So going back to my original claim that all DAML+OIL instance data is RDF
>>instance data...

I thought this was a finely crafted description that stands up, even if the 
intended statement is not "in" RDF.  I'm also hopeful that your work on 
closures will help us to realize some of the extension paths that are 
implied here.


Graham Klyne
Received on Tuesday, 16 October 2001 08:25:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:46:14 UTC