RE: The Tragedy of RSS

[Mike said]
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>?

 [Danny says]
 The RDF/XML syntax has its failings all right - the redundancy of
Description has been mentioned before. In its defence, the idea of having a
block describing a resource does make sense, although as you say this can
obscure the triples. RDF is after all a graph model, and a graph can be
expressed as triples. Assuming we want an XML serialization (we do, IMHO)
then no matter what is done the structural mismatch between the graph of RDF
and the usual tree of XML, which is bound to lead to some syntactical
ugliness.

I'm not sure I agree with your criticism of the striped syntax - when it can
be applied, it's quite a useful way of viewing the information. Check out
http://groups.yahoo.com/group/rdfweb-dev/message/330
(which should have indentation like this >  )


You mention IP - it's possible to successfully run a network of any size
without knowing the internals of the protocol. With RDF, I think the
expectation that carries over from other XML languages, that it's possible
to write documents from scratch in a text editor, may be a little misguided.
Ok, so parser builders need to know the syntax, but tool builders just need
an API. This isn't an issue with most XML, but surely quite a proportion of
developers could get on with their jobs with only SAX/DOM to work from.

[Mike said]

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.

[Danny says]
Hmm - I'm not sure there are mixed metaphors, or any real grand unification.
The fact that 'Class' is well overloaded in both linguistic and programming
use is unfortunate, but the MT does formalise what is meant by the term in
this context.
Your point about the sovereignty of the predicate is good, and though I have
had doubts in the past about the nature of properties in RDF, I agree that
the interesting bit starts when you start joing the dots.

[Mike said]
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.

[Danny says]
You may well be right about the disjunction, but whether or not there is a
bolt of lightning (it would be nice ;-) what the RDF M&S offers at present
is a pretty reasonable place from which to explore. I must admit the
property-centric approach you're talking about does sound worth pursuing,
but I think maybe this could be done at the application level rather than
needing to be done in the model.
Incidentally, most of the problems I've personally encountered have had a
lot more to do with context issues than the syntax, but perhaps if the
syntax had been simpler then more people would be out there fixing the bugs.



  [Mike re. custom XML]

  IThere 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.

  [Danny]
  I'm not too convinced by this argument - the adoption of XML would make a
strong counter argument.


    [Mike]

    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".

    [Danny]
    1. Unless we used a purely graphical syntax, I'm not sure a direct
mapping is that achievable. I'm pretty sure there have been XML-triples
syntaxes passing through this list in the past, but anyway it isn't too
difficult to imagine what they'd look like. Personally I'd need to see a few
examples of it used with different vocabularies before being convinced that
it was an improvement - I suspect RSS expressed in this way might be a
little verbose for most tastes.
    2. I disagree - reification or a variation seems to be needed to handle
some of the context problems (e.g. saying where a statement was made). I'm
not convinced that reification is the best answer,  it's certainly 'the Big
Ugly' (as Shelley Powers memorably described it). But without alternative
mechanisms, I think it is need (I could well be wrong - I'm not seen how TAP
handles this sort of thing).
    3. You can embed RDF in existing XML documents, though admittedly there
are DTD problems like those that have been identified with XHTML. I do agree
more work is required to make it as easy as possible. The atom I suppose is
the description, which could be a single statement.
    4. I'm not sure what you mean by 'simple metadata characteristics', but
certainly for things like datatyping I agree. But in many respects I think
XML schema is orthogonal to RDF. Heh - dual paths? What about Relax NG and
all the other schema languages?


    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.

  [Mike]
  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.
  [Danny]
  Agreed, agreed, agreed. But in the third case I think what we have is good
enough to start using, and being realistic I can't see the RDF WG making a
complete fresh start, and I don't think there are presently any
organisations with the same kind of processes and clout as the W3C to be
able to develop and get such a standard adopted.
  I suppose in an ideal world RDF would have been a 5-year project with the
deliverable being a disposable prototype. Then RDFNG would incorporate all
that had been learnt and would answer everyone's prayers. etc. You never
know, Dave Winer might have a bright idea ;-)



    Keep stirring the pot!


  [Mike]
  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.
  [Danny]

  Well, I admit that my responses do tend to be somewhat for arguments sake,
but I do think it's crucial for people in the trenches like yourself to
express your concerns, and I'm pretty confident that the WG folks are
listeneing.
  Good luck with the project!

  Cheers,
  Danny.