Re: RDF semantics: applications, formalism and education

At 02:37 PM 4/3/01 -0700, pat hayes wrote:
>>I think there is a range of applications for which the expressive power 
>>of basic RDF is adequate.  (e.g. RSS, calendaring, directory metadata, 
>>message metadata, web page metadata, etc., etc.)  I think these will 
>>typically be applications in which human participants are still directly 
>>involved.  For these applications, the expected value of using RDF is (a) 
>>to leverage common tools, and (b) to ease the movement of (RDF-coded) 
>>data between different applications, or to be able to combine data from 
>>multiple applications.  Prosaic stuff, but still valuable.
>
>Agreed, and any standard needs to accomodate this good stuff. But this is 
>not an argument for RDF in particular, as almost any notation could do 
>this. [...]

Agreed.  I think the main argument for RDF in particular is the mindshare 
it has generated.

[...]
>Just to clarify, I (the original grouser on this thread) did not intend to 
>suggest that 'full semantic expression' should be in the core. In fact I 
>don't really have a problem with the RDF core *if it is seen as a core*. 
>It is just a datastructuring tool, and in that role it is as good as any; 
>my problem is that it isn't described that way, but is put forward as a 
>universal semantic model. And in that role, it just isn't up to the task.

I'd like to think that in here is something we can build on.  To be clear 
about what RDF (the core) is and is not;  leverage it's current 
applications (e.g. RSS, et al), and properly understand how it relates to 
formal frameworks that can be built using it as a tool.

[** see below]

>>The fact that we might build different semantic frameworks on that core 
>>is a real strength at this time.
>
>I think you are using 'semantic' in a different sense. It makes sense to 
>have different extensions to a core. It doesnt make sense to have 
>different ways of interpreting a core (or any other formal language), 
>since that renders it incapable of communicating content; if the same 
>formalism has alternative semantics, then what I mean when I send 
>something to you might not be what you read it as saying. And if this IS 
>the language we use to communicate in, we have no way of even discussing 
>what the differences might be, since everything I say to try to clarify 
>your misunderstanding can itself be misunderstood. This is not a source of 
>strength; it is the curse of Babel.

Er, yes, that was sloppy of me.  I think I meant to say different 
formalisms (which would be clearly, syntactically signalled within the RDF 
framework).

.....

[** Thinking...]

Maybe we need to review and clarify the architectural framework.
I can imagine something like this:

Logic:           DAML+OIL, etc  (Full-strength inference, typing)
Schema:          RDFS           (Limited inference, typing)
Abstract syntax: RDF            (Directed labeled graph)
                  XML Infoset    (Annotated tree)
                  XML Namespace  <<--------------------- URIs
Syntax:          XML            ("Pointy brackets")
                  Characters     (Unicode, UCS, others)
                  Octets         (Pretty universal now, not always so)
                  Bits

Different kinds of application can sit on different levels of this 
"Stack".  All computer applications ultimately sit on 'bits', and most sit 
on 'Octets'.  Unicode/UCS is becoming the norm for applications using 
character-coded data (text, XML, and more).  E.g.  it's standard in Java.

Today, there are many applications that sit directly on the XML layer 
(+URIs):  many of the current W3C recommendations specify XML applications.

XML Infoset (if I understand correctly) is an abstraction layer that might 
allow XML to be based on non-character representations.  Applications based 
on this (using DOM?) should be isolated from the underlying character syntax.

I see the RDF abstract syntax as a simplification and generalization of the 
underlying XML on which it is based.  Hopefully one which lends itself 
tolerably well to the construction of higher semantic layers.  I think this 
abstract syntax is a significant step towards being able to truly exchange 
information between different applications (TimBL gives an example 
somewhere of an invoice containing information about airplane 
parts:  financial management data meets engineering design data).  I see 
current RDF applications (RSS, CC/PP, etc as mainly operating at this layer).

The next layer, and probably the most difficult to judge correctly, I have 
called the RDF schema layer, encompassing the basic ideas that lead to 
primitive inferencing (rule following) and typing/classification of 
resources.  I don't know if this is possible, but I think it would be a 
useful goal if evaluations defined at this level were guaranteed to be 
computable;  i.e. to terminate in finite time.  I understand that this 
excludes full FOL.  I think this could be a basis for a range of simple 
processing tasks -- possibly a majority of those performed over the Web 
today.

Then there's the full logic layer, characterized by DAML+OIL.  This would 
include the "universal web proof checking engine" that has been 
proposed.  This layer would support a range of what might be called 
knowledge applications.

...

In setting out the above, I would hope to sketch a framework in which we 
can usefully discuss what capabilities should be defined where;  in 
particular, what are the appropriate levels of functionality to be designed 
into the RDF and RDF schema layers?

#g


------------
Graham Klyne
(GK@ACM.ORG)

Received on Wednesday, 4 April 2001 08:17:56 UTC