RSS and RDF

Hi,

I wanted to forward this post from egroups rss-dev. I'm prone to moaning
about RDF XML syntax from time to time but not as articulately as this man,
Bob La Quey. It does talk about RDF as a function of RSS, but has a nice
overview of the value of a simplified syntax and the usefulness of out of
document metadata. 

-Bill de hÓra


Hello folks, 


A brief introduction. At 59, I sometimes feel I am the world's   oldest
programmer, but I still enjoy the process and have   stayed relatively
current with web technologies. I am currently working with Mozilla and
metadata with several younger colleagues in Mexico. I was educated
originally as a theoretical physicist so   it is natural for me to think in
terms of abstractions, and using those abstractions, wherever possible, to
simplify the solutions to problems. 

I have read the message archive, many of the W3 standards, and feel that I
have done enough homework to join in the discussion of RSS. I apologize for
the length of this message but I wanted   to put most of the pieces in one
place. Feel free, to hack it up,   flame away, etc. I am a tough old coot
with a thick skin. 

When I look at RSS 1.0, I see the tensions between simplicity,
extensibility and backward compatibility as were described by Eric van der
Vlist, http://www.egroups.com/message/rss-dev/219?threaded=1


1) Transformations are not a temporary kludge.
2) RSS 09 and O91 are not the champions of simplicity but compromises.
3) RSS 1.0 is bringing back the spirit of RSS 09 packaging the RSS091
functionality as an optional module.
4) RSS 1.0 is meeting a strong demand for extensibility.
5) RSS 1.0 is a compromise (like RSS 09 and 091).
6) RSS 1.0 is slightly more complicated to write by hand.
7) New tools are available and more are on the way.

To which I would add the following criticism: 

RSS 1.0 is made significantly more complex then necessary by: 

1) The execrable XML syntax contained in the RDF recommendation  from the
W3C, http://www.w3.org/TR/REC-rdf-syntax/
2) The requirement for backward compatibility with RSS 0.9 

Thus as we look toward the future of RSS I would like to explore   the
following propositions:

1) RSS 1.0 be considered a transitional recommendation 
2) RSS 1.x be significantly different in two ways 
a) backward compatibility with RSS 0.9 be dropped, if need be, put RSS 0.9
in a module. 
b) an alternative RDF syntax be used. 

This latter is far and away the most important puzzle. I am   aware of
several proposals for simplifying the XML syntax used to serialize RDF. My
position this is as follows.

RDF has a beautiful data model, sweet, simple, but very powerful. It is the
XML serialization syntax which has been botched by the W3C.

The RDF syntax used in RSS 1.x is simplified with no loss of power.   RSS
1.x uses a simplified syntax to integrate RDF into RSS.   Tim Berners-Lee in
his design issues Strawman note suggested   requirements for simplifying RDF
syntax. Taking his lead from this   proposal, Sergey Melnik has developed a
Simplified Syntax for RDF,   which allows mixing of XML and RDF. Melnik's
scheme uses three XML   attributes, which have meaning to an RDF processor,
to markup the XML   and thus is applicable to existing XML documents. The
proposed XML   attributes controlling the behavior of the RDF processor that
are used   in this document are: 

rdf:instance (says that the containing tag is a class name) 
rdf:for (the containing tag is a property name, the value 
         of the attribute is the subject URI) 
rdf:resource (the containing tag is a property name, the value 
              of the attribute is the object URI) 

rdf:instance cannot be used together with rdf:for or rdf:resource. 

The elements rdf:RDF and rdf:Description are no longer needed thus   they
are dropped from the list of RSS 1.x proposal Core Elements. Also the
inchannel element is not needed since the RDF syntax is   unambiguous.   

The RDF abbreviated syntax is no longer needed or allowed. 

I would note that use of Sergey's scheme to annotate XML   may be done
either "internally" i.e. the usual way with the XML elements having the
attributes written within the pointies, or externally as Aaaron Schwartz has
suggested in a separate file. Further note that Aaron has suggested using
the separate file for carrying the RDF info but not specifically using
Sergey's approach.

There is a lot more to be said for an external file approach. 

From our good friends at the W3C, 
http://www.w3.org/XML/Linking
http://www.w3.org/TR/2000/CR-xptr-20000607.html

<quote> 
XPointer, which is based on the XML Path Language (XPath), supports
addressing into the internal structures of XML documents. It allows   for
traversals of a document tree and choice of its internal parts   based on
various properties, such as element types, attribute values,   character
content, and relative position.   </quote>

So in implementing Aaron's approach we use XPointer to point into the
underlying original XML document. We add Sergey's attributes   as a separate
overlay file which simply consists of a collection of (rdf:attribute,
XPointer) pairs. 

Now the interesting thing about this approach is that we can build   can
build RDF overlays for multiple sets of underlying XML files. In essence, we
construct the semantic web as a separate RDF web on   top of the XML web,
which we point at using XPointer. 

I think this is actually pretty neat. To actually construct the   semantic
network you must of course traverse the underlying XML   in order to
construct the RDF triplets from Sergey's attributes   and the XPointers but
is is a pretty nice decoupling of the two   spaces XML and RDF. 

The XML world just goes its merry way and we annotate it   with semantics
whenever we get around to it.   

Disclaimer: I admit to being totally ignorant of the details 
            of how XPointers are formed and of the syntax of their
            expression. Nothing above is intended as an endorsement
            of the particular form in which the W3C has rendered 
            the basic idea of an XPointer as expressed in the paragraph
            quoted above.  

So there are a number of design issues here: 

1) is the RDF info to be in the same file as the XML? 
2) how does one represent the RDF info that must be added 
       to XML?  

I could go on, but I will wait for feedback and a dialog to develop. 

Relevant URLs are: 

Sergey Melnik 
http://www-db.stanford.edu/~melnik/rdf/syntax.html
http://www-db.stanford.edu/~melnik/rdf/fusion.html
http://www-db.stanford.edu/~melnik/rdf/api.html

Tim Berners-Lee 
http://www.w3.org/DesignIssues/Syntax

RDF is really nothing more than a named bag of (Property, Value)   pairs. A
Value can be such a named bag i.e. a Resource so the system   allows for
indirection and can just be used to build arbitrary networks. Properties are
themselves a subset of Resources so may be qualified   using RDF itself.   

Here is what Sergey is saying about a simple syntax. 

We can certainly express (Property, Value) pairs as 

<property>value</property>   
...

i.e. elements is a perfectly reasonable way to describe   a bag of
(Property, Value) pairs so let that be the default   representation. 

Now, sometimes you have a element which is NOT a property but is instead an
rdf subject so you annotate that property   with the rdf:resource=URI
attribute, e.g. 

<cat rdf:resource="http://www.animals.com/cat>
     <color>gray</grey> 
     <name> Sam Sam </name>
</cat>

I now, for the first time see a reasonable time and place to use attributes
in a consistent way. 

Consider attribute free XML. Now the purpose of attributes   is to "mark up
the elelents". 

<mantra>
   Elements markup the content (the Values) 
   Attributes markup the Elements. 
</mantra>

It is as simple as that. 

So I now, for the first time, accept attributes as having a useful role in
XML and see a very clear cut statement of when   and where to use them. 

What Sergey Melnik has noticed is that one 
can take existing XML and mark it up in a completely   unambiguous way for
RDF interpretation by using 

1) the default rule that an element with content 
      defines a (Property, Value) pair 

2) three names in the rdf Namesapce as 
      attributes to markup the XML elements in an 
      unambigous way. 

This is good, strightforward and simple. 

Regards, 


Bob La Quey 


PS. I belive what Tim BL is saying, which I certainly believe, is that the
RDF Data Model is sweet, simple and powerful,   (see :
http://www.w3.org/TR/REC-rdf-syntax/#model   especially the first four
statements quoted below ) but that the   XML syntax in the Recommendation is
terrible. It is a sad state of   affairs. If I were to speculatate I would
guess that what we have   in the Rec is a clssic example of a committee
tasked to design a   mouse and producing an elephant. 


<quote> 
The RDF data model is defined formally as follows:


There is a set called Resources.   
There is a set called Literals.   There is a subset of Resources called
Properties.   There is a set called Statements, each element of which is a
triple of the form   {pred, sub, obj}


Where pred is a property (member of Properties), sub is a resource (member
of Resources), and obj is either a resource or a literal (member of
Literals). </quote>


Bob La Quey

Received on Tuesday, 10 October 2000 03:51:52 UTC