Re: The Tragedy of RSS

Hi Danny,

Thanks for your thoughtful responses ... more below...

In a message dated 10/5/2002 3:34:11 AM US Mountain Standard Time, 
danny666@virgilio.it writes:

> There is a lot of interesting points in the article but I don't know if we
> are ready for additional complexity (via deeper grounds) yet.  I think
> every complex feature must be tied to a direct benefit.  The chief 
> complaint
> from RSS developers that I see in the newsgroups is that RDF adds
> complexity without any extra features or benefits.  They don't see the
> benefit -- and I don't either with respect to RSS.  For me, I see 
> ontologies and inference as demonstrating a clear value added.  Until we
> have those quibbling over the syntax of simple syndication seems like
> a waste of time.   Why?  Because when the time comes that we have
> robust ontologies and robust inference mechanisms -- enough changes
> will have occurred to the syntax to make existing RDF moot.   
>  
> You're creating something of a chicken and egg situation here - to make 
> robust ontologies and inference mechanisms, some lower-level language(s) 
> will be needed. It could be done using something other than RDF (such as 
> KIF, or something completely new), but seeing as RDF by design encompasses 
> web-awareness and the architecture is flexible enough that virtually any 
> ontology/inference mechanism can be layered on top.   
> 

I am all for the layered design and agree that is the right approach as it 
has been
proven successful in numerous other domains (Operating systems, networking, 
etc.).
Having said that, the lowest layer MUST BE the simplest, most intuitive and 
most
stable to adequately support the rest of the structure.  Look at IP -- very 
simple and 
only offering a few guarantees (limited scope).  In my opinion, RDF is close. 
 Surely the
S,P,O model is simple.  But the model is completely obscured by poor syntax 
choices and the hierarchical nature of the striped syntax.  For example 
<rdf:Description> ... why use the word Description (which is generic) and not 
the 
more direct mapping <rdf:Statement> or <rdf:Triple>?  

Also, IMO, the mixed metaphors are bad design ... is the RDF S,P,O trying to 
model
a linguistic statement or an OOP Class?  While RDF Schema shifts the balance 
toward
class/subclass hierarchies ... the S,P,O leans towards the more linguistic 
and non-contextual
assertions.  Both are powerful and maybe the grand unification is a stroke of 
mastery ... but ...
the unification has problems ... for example:

S,P,O assertions place a higher priority on relations.  The P is where the 
power is at because it
forms the connection.  Let's face it, we have gobs of experience on storing 
information about
nouns (things).  We have not fully exploited predicates and every briefing I 
do on this
subject -- people get excited about the verb connections.

An analogy ... the military has a concept called "asymmetric threat" -- this 
is a threat that
does not follow the regular, symmetric rules of combat ... such as using a 
plane as a weapon.
To identify these threats is all about RELATIONS.  That is how you find them 
by tracking 
any and all relations between normal threats and all potentialities that 
could be threats.

Standard OOP class structures bury associations in the hierarchy.  You must 
get 
the class name and check the type of each property to find the association to 
another
class.  Burying is bad for something that could be the next potential killer 
app.  S,P,O
puts the P front and center but then RDFS buries it again.  Something is 
disjointed.
I wish I could solve it right now but I'm not that quick ... all I know now 
is something is 
out of whack ... I'm still waiting for the bolt of lightning.


> Since I am stirring the pot -- let's throw in another slap in the face -- 
> WSDL.
> It is evident that it is a description of resources ... but no RDF in 
> sight.
> Why fight with one hand tied behind your back?  Why push a bad design. 
>  
> The existence of WSDL says very little about the design of RDF.

I agree but it says boat loads about the adoption of RDF.  It is not even on
designer's radar screens when they are trying to solve a problem that is 
easily
considered the domain of RDF.  Not capturing that mindshare is a key 
indicator
that there is a problem.  If you don't have mindshare, you certainly don't 
have adoption.


> That the non-RDF approach requires a completely new XML language for every 
> domain (RSS and WSDL mentioned so far) says a lot about that general 
> approach. The semantics of syndication and web services can be expressed 
> using RDF (RSS 1.0 & DAML-S respectively), and the same tools can be used 
> on both. Now how would you suggest setting up interoperability between 
> information expressed in RSS 0.9x and WSDL?     
> 

There is some built in interoperability just looking at the atomic elements 
--
1. identical elements (same namespace) are instantly interoperable.
2. identical URIs are talking about the same thing.  

Beyond that you are on your own with XSLT and a custom solution.

Having said that ... many customers don't care about completely generic 
solutions.
There is a realization that the more generic, reusable, flexible, etc. you 
get ... the 
higher the implementation costs.  For example, I did a lot of work for Fannie 
Mae and 
to be frank: they don't care about a solution that satisfies everyone ... 
only a solution that
satisfies their partners WHO THEY KNOW and have worked out legally binding 
agreements with before hand.  Here is their yardstick to a successful 
solution
between partners: If I have to send out a PHD to explain it to my partners 
--- forget it.


 > 
> At what point do you go back to the drawing board and say --- many
> people think this is broke.  Let's take an axe to it.
> 
> In what respect is it broken? There are ongoing problems, but this is 
> largely because a lot of new territory is being explored. 

I believe RDF is broken in the following ways:
1. the mapping between the RDF model and syntax is not direct, straight 
forward and simple.
I would like to see a simple XML version of triples.
2. reification has not proven itself useful and many implementations (like 
TAP) explicitly avoid
it.  I believe this is part of the linguistic/OOP tension discussed above.
3. you cannot embed RDF in existing XML documents.  What is the "atom" of 
RDF?  I believe
it is the Statement and I should be able to put an RDF statement anywhere.
4.  Using RDF to capture simple metadata characteristics is, in my opinion, 
the weakest
example of knowledge capture and is adequately served by XML Schema.  More 
importantly,
we need a unification between the two.  Dual paths is bad.  RDF and XML 
Documents
(via XML Schema) should be one story and not two.  I believe they are 
currently seen as
two stories and thus the RDF story is ignored as being "out there".


> The difference is that whole layers of solutions are generalised, so once a 
> problem is solved in one domain it is solved in all domains. It's a bit bit 
> like the old "Give a man a fish and he will eat for a day, teach him how to 
> fish..." (or whatever). 
> In this analogy RSS 2.0 is a fish.
> 

Yes, but the generalities must be solid.  Also, the general building blocks 
have the easy
ability to be assembled into specific solutions.  I don't believe this is the 
current case.
 
> 
> Keep stirring the pot!
>  

I hope people don't feel I'm doing this just for arguments sake.  I am also 
in the
trenches seeking and trying solutions.  I am the architect of a project 
called the 
"Virtual Knowledge Base" whose goal is to semantically integrate 
heterogeneous
data sources.

Best wishes,

 - Mike
----------------------------------------------------
Michael C. Daconta
Director, Web & Technology Services
www.mcbrad.com