[Dev] RDF as description

[David McCusker]

This is not the RDF primer I'll write sometime.  This is just my
explanation of why I'm not anti RDF, despite my not embracing it
fully at all times as the best way to characterize our system.

RDF stands for resource description framework.  I think it works
great for description, and I'm all for using it in Chandler.  None
of my comments have an aim to reduce RDF usage.

(The parts of RDF I find confusing mostly concern other standards
integrated with RDF, which hold understanding basic ideas hostage to
arcane details of Unicode, XML, URIs, etc in serialization matters.)

A strong point of RDF, and perhaps the motivation for using such a
thing in the first place, is the ability to describe content in our
computing systems without resorting to a code programming view.

 From a coder's point of view this is not efficient or clear because
more straightforward ways of expressing the same type of things appear
in programming languages, albeit a little differently in each one.

A declarative approach in a languages system like RDF makes it easy to
express desired semantics without getting entwined in problems of when
code execution occurs.  This is great for domain experts in documents.

But this approach obfuscates what can and should happen in a system
which executes code in order to effect meanings behind declarations.
So RDF is weak at supporting efficient code when all code is ignored.

High priests in charge of coding systems have been in charge too long
however, and we tend to describe computing systems with large numbers
of buzzwords, which subtly and falsely suggest only coding matters.

Our systems are really just executing simulations.

The simulation from the user's point of view is what really matters.
It helps when we can use tools like RDF to express desired simulation.

But that doesn't make RDF "real" in the system, in the sense that it
must go all the way down to computing bedrock, and hold every position
in between from top to bottom.  It's just another simulation.

I see RDF as a specification of what an app simulation should be doing
at the point of overlap between user content and backend knowledge.
As such, it's a plan and an explanation of what an app is really doing.
(Or it could be.  Currently RDF might be slightly too self involved.)

When apps interact, RDF can be a lingua franca for standardization when
no other more efficient language is at hand for communication.  And it
could serve as the entry point to negotiate more efficient languages.

But the point is that engines can be executing machinery that has not
much of anything to do with RDF.  However, RDF can still be used to
say what the machinery is doing, and it can be an interface language.

End users typically see a graphical front end as the primary app face.
If we expose RDF from the guts of an app, this might look like a view
of the backend to end users.  But it's just a view of the simulation.

A backend engine needn't use RDF in any way until and unless one wants
to lazily translate backend activity into an RDF based description.

Ideally RDF should clarify backend internals.  If it doesn't, then the
primary purpose of RDF appears to fail.  When describing backend code
engines is clarified by using another approach, we should do that.

Especially when RDF confuses folks who want to help us with Chandler,
I hope we have another way to say what the system is doing, for sake of
variety, and for clarity when redundant specs reinforce each other.

In development, we'll describe some mechanisms without RDF appearing
in the picture.  This doesn't mean RDF has been removed from Chandler.
It just doesn't appear in that description.

Sorry about the long piece.  I was trying to short circuit a few future
gnarly arguments about the place of RDF in the project.  Some of the
things we'll do won't be as contradictory as they seem at times.

--David McCusker