Introduction: Graham Klyne

I've been involved with RDF for a few years now, originally coming to it 
from a perspective of metadata for content negotiation.  Through my 
subsequent work in the RDFcore working group, I bear some responsibility 
for the failure to capture some essence of "social meaning" in the RDF 
specifications, but I'm happy that the proposed text has been discarded in 
favour of a more broadly-based discussion of what is clearly a tricky issue.

While I have always been very keen on formal semantics for RDF, I also 
believe that this is not the whole story, and we should try to articulate 
those informal ways in which the meaning of RDF affects (or can affect) 
operations in the "real world".  I see formalization as an evolving process 
that will converge towards (but never reach) some ideal of total 
formalization of information.  I see the current state of RDF representing 
early steps on such a path, with far to go.

I also believe quite strongly that lack of understanding or consensus about 
informal aspects of the meaning of RDF should not prevent us from *doing* 
things -- anything we find useful -- with RDF, and experimenting 
pragmatically with various forms of inferencing/processing of RDF data.

I am currently working on building pragmatically-derived inference tools 
for RDF in Haskell (a pure functional programming language that is itself 
relatively susceptible to formal analysis).  One of my incidental sub-goals 
is to develop a model for describe RDF datatype inferences using Haskell 
(an area of meaning in RDF that remains largely unformalized).

The application area that currently drives my interest is configuration and 
monitoring of computer network devices and applications (e.g. [1]).  To the 
extent that the meaning of RDF can be formalized, I think that common 
software can be used process RDF data, but this must be blended with 
application domain knowledge that is not (yet) captured in a formal 
way.  To this end, I will use RDF to *encode* various kinds of information 
in ways that I can use to make some software work, and then try to figure 
how it works with existing formalisms -- I think such work can help 
motivate efforts to push at the boundaries of meaning in RDF.

...

Personally, I don't find routine teleconferences particularly useful, and 
prefer to concentrate on technical discussions in email where I can come to 
terms with issues at my own (slow) pace.  As such, I'd favour less-frequent 
or as-needed teleconferences.  Currently I have one recurring weekly 
commitment, Friday afternoon UK time (mid-morning EST).  Family 
expectations make late evening teleconferences (e.g. running later than 
7:00PM, UK time) difficult for me to participate in on a regular basis.  I 
have all-day commitments on 15-17 and 23 September, otherwise I'm currently 
pretty flexible.

#g
--

[1] http://www.ninebynine.org/SWAD-E/Intro.html#HomeNetAccessDemo



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

Received on Saturday, 6 September 2003 12:37:49 UTC