W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > April 2001

Introduction: Graham Klyne

From: Graham Klyne <GK@NineByNine.org>
Date: Wed, 11 Apr 2001 21:23:15 +0100
Message-Id: <>
To: w3c-rdfcore-wg@w3.org
Introduction to RDFcore WG for:  Graham Klyne

I am involved in "strategic research" for the content security group of 
Baltimore Technologies.  I think there are a number of ways in which RDF 
can provide a foundation for some of our product developments:
- modelling of security and trust (web of trust, etc).
- standards for content labelling (metadata).
- a framework for combining information from multiple data sources.
- a common framework for expressing a variety of information ("content"), 
which can serve as a basis for detecting patterns of usage or content in 
network protocols.

I came to RDF through my work in the W3C CC/PP working group, and prior to 
that in the IETF media feature registration working group (CONNEG).  In 
CONNEG, I proposed and documented a framework for content capability and 
preference description that used a well-defined logical framework to match 
document characteristics with recipient capabilities and preferences.  This 
framework provided a common framework, independent of any particular media 
feature, for matching these capabilities, but did impose some significant 
restrictions on what kinds of capabilities could be expressed.

The CC/PP work has been much more one-sided, focusing on describing client 
capabilities and preferences and requiring that an origin server, or other 
data provider, will know enough about the specific features described to 
select an appropriate form of data resource to be provided.  In due course, 
I think this framework must be extended to sender-side descriptions (using 
RDF) so that the document/capability matching can be done away from the 
origin data providing system.  Such a framework will ideally be based on 
some standard RDF developments rather than ad-hoc features.

I see the work of this group, in part, as laying some foundations for such 

I believe that the basic ideas of RDF, as currently defined, are very 
strong:  the representation of metadata and other information as labelled 
relationships between resources being described.  However, the current 
specifications are not easy to read, and sometimes seem to pose more 
questions than they answer.  Also, recent discussion on the RDF-logic 
mailing list has raised the spectre that the formal basis of RDF is 
inadequate for the things we expect RDF to be able to express.

I would see this WG having the following targets:

1. simplify the current specs -- remove things that do not need to be in 
the core specifications, and allow them to be defined as vocabulary 
extensions to the RDF core.

2. provide clear formal foundations for the core specifications:  (a) to 
understand the extent of formality that is to be embodied in the RDF core, 
and (b) to ensure that the formality that is present is a logically sound 
foundation for further development.

3. clarify the current specs -- make them easier to read and 
understand;  separate core ideas ("model") from the details of XML 
syntax;  be very much clearer about what concepts are represented in the 
core "model", and how these

4. clarify/formalize the relationship between URIs and RDF resources:  this 
seems to have been a cause for much miscommunication about the 
interpretation of RDF.

5. N3 -- for human discourse about graphs:  the RDF/XML syntax is not an 
easy syntax for human discourse.  Nodes and arcs are all very well, but 
difficult to capture in emails and documents.  N3 seems to neatly capture 
some middle ground here, and it _might_ be worth this group's while to 
clean up the N3 spec (possibly as a W3 NOTE) to provide an easier means to 
talk about RDF ideas in email and other documents.


The above outlines my hopes for this group.  In another message, I'll 
outline some thoughts about how I see some of these (ambitious) goals might 
be tackled.


Graham Klyne
Received on Wednesday, 11 April 2001 18:21:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:00 UTC