- From: Graham Klyne <GK@NineByNine.org>
- Date: Tue, 16 Oct 2001 13:14:36 +0100
- 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. #g ------------ Graham Klyne (GK@ACM.ORG)
Received on Tuesday, 16 October 2001 08:25:55 UTC