RDF for working programmers?

At 12:34 PM 11/21/02 -0600, Shelley Powers wrote:
>But I'm literally between a rock and a
>hard place -- between the average Joe wanting to use RDF for a door factory
>in Wisconsin, and those in white coats who see RDF as the cornerstone for
>some grand, esoteric semantic web. And, in some way, I have to define what
>is the "Practical" aspects of RDF.

I think you touch on something here that's both exciting and frustrating 
about working with RDF.  I think we're at the start of a ramp that will 
introduce a range of new ideas into mainstream computer application 
development.  (By new, I mean new to the "mainstream":  most of the ideas 
are very old.)

I've just spent a week with folks who design Internet protocols, and have 
talked to a few about my semantic web work.  Many are quite sceptical, but 
I have found that it is the small, practical applications that people find 
most engaging.

But I am also aware that for even these simple applications to be built 
from common tools, rather than new software, we need some of the less 
obvious aspects of formal semantics to underpin the way these tools 
work.  Part of what we're trying to do is abstract the essential logic that 
we thrash out in our C or Java or Python code into a simple data format, 
and have generic tools recognize that logic and do the right computations.

I've recently adopted the mantra "a little inference goes a long way" with 
respect to RDF and semantic web technology.  By way of example, have you 
looked at Dan Connolly's work on generating graphs from RDF using GraphViz 
[1]?  This is a really simple, prosaic application of RDF, but it depends 
in subtle ways on its formal capabilities.  The whole process is performed 
with small standard applications (cwm, XSLT, GraphViz), yet can be used to 
produce fully customized graphs from arbitrary RDF data.  At the heart of 
this process is a simple inference rule to define the required graph, 
looking something like this (in Notation3):

{ <#x> a protocol:Protocol ; rdfs:label <#y> } log:implies
   { <#theGraph> gviz:hasNode <#x> .
     <#x> gviz:label <#y> ;
          gviz:shape     "ellipse" ;
          gviz:style     "filled" ;
          gviz:color     "violet" ;
          gviz:fontcolor "white" ;
          gviz:fontsize  "32" } .

and declaration of a few additional RDF facts to control 
presentation.  This one inference rule is responsible for selecting what 
RDF nodes appear in a graph.

To do all this stuff, we're depending on some features of RDF that need to 
be well-defined, even if not every user has to understand them.  So who are 
our audience?  I think it's a whole range of people:  I think a crucial 
early audience is RDF tool designers, for whom the underlying subtleties of 
RDF must be defined.  But also are application programmers and information 
designers who probably can work with a far less detailed understanding of 
the nitty details (maybe until they start to meet advanced inferencing 
tools which may one day be the workhorses of the Semantic Web).

In summary:  I think there are important ideas in RDF that will be new to 
some of our intended audience, and we need to figure out how best to 
present them, and how much of them needs to be presented.

#g
--

[1] http://www.w3.org/2001/02pd/



-------------------
Graham Klyne
<GK@NineByNine.org>

Received on Tuesday, 26 November 2002 13:37:57 UTC