Understanding RDF for CCPP use

Folks,

Writing from the perspective of a CCPP WG participant, I have some 
questions and comments.  (Writing as an individual and in no way 
representing the CCPP group.)  I find much resonance with some comments 
recently made here about the presentation of RDF concepts -- I've found it 
a long hard slog, and still have barely scratched the surface.


I noted Lorrie Cranor's recent comment about trying then abandoning use of 
RDF for P3P.  While I sympathize with the group's reasons for not using 
RDF, I am thinking it's a great pity because the benefit from RDF should be 
all greater if used for different types of metadata -- after all, that's 
the whole idea, isn't it?  (For example, an RDF form of P3P in conjunction 
with CCPP negotiation metatadata might be used by a corporate firewall to 
monitor the release of internal information, where the corporate policy is 
itself expressed in RDF...)


Reading through Tim BL's web architecture document series, I have just read 
"Metadata Architecture" (<http://www.w3.org/DesignIssues/Metadata.html>), 
which I think provides a good deal of background information.  Here are 
what I see as some of the key points:
- Attributes are assertions about resources.
- Attribute assertions must be independent.  (Each assertion stands 
independently of any others that may be made.)
- A set of attribute assertions should be expressible without explicit 
reference to the resource to which they apply.
- Attribute assertions involve:
   + an attribute name/identifier
   + a subject resource
   + one or more parameters (which may themselves be resources)
- The set of assertions that can be made about a resource is never closed
- Metadata is data, and can itself have metadata (smaller fleas...)
- A "link" is a kind of assertion that may be used to represent the 
structure of metadata OR as an attribute in its own right.  (See below)
- There is a potential confusion to be avoided:  labelling the content vs 
labelling the container.
- If one can make some assumptions about the properties of metadata, then 
it can be manipulated even if the meaning of the vocabulary used is not 
fully understood.  The paper goes on to mention a "common vocabulary for 
logical functions" sometimes known as the "RDF upper layers".

QUESTION:  does the above still represent current thinking about RDF?  Have 
I got this much approximately correct?


I do think that there are some principles here that should guide the CCPP 
group's use of RDF.  There are still some points that concern me...

It seems that properties (RDF graph edges) can be used for assertions and 
for structuring values.  I find this overloading rather uncomfortable, and 
would seek some way to clarify the distinction between these forms.  Is 
this reasonable?

It is not clear in the architecture document how logical forms other than 
simple conjunction should be handled, though I feel the architecture 
clearly envisages these.  It's also not clear how (say) complex logical 
expressions would be supported in the face of assertion independence 
(though I might imagine some approaches).

I don't know how RDF represents assertions with more than one parameter, 
which are clearly mentioned in the architecture.  (The idea of assertions 
with more than one parameter might be how, say, inequality comparisons 
might be represented).

Current approaches don't seem to support the idea of describing 
capabilities without explicitly indicating the subject resource to which 
they apply.  Does RDF provide a way to do this?


#g

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

Received on Wednesday, 1 March 2000 08:35:46 UTC