On 9 Jul 2006, at 12:18, Elliotte Harold wrote
Henry Story wrote:
But as Kuhn [2] and Feyerabend [3] have very well argued, these
types of debates are not won through argument. People work within
paradigms that forge their vision of the world. So that
counterexamples will always be pushed aside.
I agree that these debates are not won through argument. I don't
agree that they're not won through counterexample, or at least that
counterexample isn't a critical component of debate winning.
Ok. I will try.
I look at your N3 example and I don't see anything there that isn't
in the XML form. Most importantly I don't see what it buys me. I
don't see how it makes my life any easier than non-RDF XML, or how
it lets me do anything I can't already do.
Well I am happy that it has achieved that. I have very purposefully
designed the ontology to say exactly what the atom spec permits one
to say, even when at times it felt like one should be able to say
more, or should be less rigid. So that is by design. I want atom
people to be able to understand rdf off the bat, with minimal
learning - intuitively.
Atom has done one very good thing. It has formalised the intuitions
of many. I have just built an ontology to respect that intuition.
Regarding xml and rdf, I feel that there is still one tool that we
need to make xml and rdf people be able to live happily together. It
is what I will call an xml crystallization of an rdf graph... But it
is a thought that needs to be re-developed. RDF/XML has failed as an
xml serialisation in part because it does not take the requirements
for rigidity that xml tools such as XPath need, seriously enough.
Now what do we get with rdf? We get an extremely clear and simple way
of building meaning out of component parts, and furthermore in a very
RESTful way.
1. RESTful meaning discovery
----------------------------
Because words are urls you can GET their meaning!
So for example what does <http://bblfish.net/work/atom-owl/2006-06-06/
#author> mean? Easy click on it and you will have an explanation in
English.
You want a machine readable meaning?
For the handwritten N3 meaning run:
curl -i -L -H 'Accept: text/rdf+n3' http://bblfish.net/work/atom-owl/
2006-06-06/#author
or for the machine generated turtle version:
curl -i -L -H 'Accept: application/x-turtle' http://bblfish.net/work/
atom-owl/2006-06-06/#author
or the ugly machine generated rdf/xml
curl -i -L -H 'Accept: application/rdf+xml' http://bblfish.net/work/
atom-owl/2006-06-06/#author
Words in RDF are self documenting.
Now how in non rdf xml are we meant to get the meaning of a new
extension term? Find the rfc that defines it? How do we do that? Then
there is text in english somewhere, with complex inheritance rules
that one needs to be a good english reader to understand. There is
somewhere else a syntax document that does not explain very much
either perhaps. Neither of these finding is easily automated.
2. Compositionality
-------------------
Atom has an extensibility framework yes. But it is not backed by a
mathematically specified semantics. So every extension will be ad-
hoc, difficult to understand, difficult to find, easy to
misunderstand. And so misunderstandings will be very common and data
very corrupt. In any case usage of the format will be a lot more
limited than it need be. In RDF it is very easy. I can immediately
use the foaf vocabulary definitions and be dead clear about what is
meant.
So here is a little N3 or Turtle (Turtle is a subset of N3)
@prefix : <http://bblfish.net/work/atom-owl/2006-06-06/#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
[ a :Entry;
:author [
foaf:homePage <http://bblfish.net/>;
foaf:aimChatId "unbabelfish";
foaf:knows <http://www.w3.org/People/Berners-Lee/card#i>
];
:title "some entry";
] .
I don't need to explain to you what the meaning of foaf:knows is. You
can turn it into a url and
find out yourself.
Now if you could show me an example of how to *use* this N3/RDF
stuff to do things I can't equally or more easily accomplish with
raw XML, then I'd pay attention. But every time I go looking for
real, practical RDF I find a huge amount of talk and philosophical
arguments but no significant, practical applications.
Ok, but I will limit myself to things concerning this group.
- I have shown how there would be no need to create a new Categories
document format. The AtomOwl vocabulary permits one to express just
that if needed.
- The whole problem of posting information that is unnecessary would
vanish. Currently one has to POST to the collection resource an entry
document complete with id, even when the id is not required. RDF
allows for missing information. AtomOwl states that an entry must
have an id, but you don't have to say what that is. (The server can
decide).
- rdf now comes with a query language SPARQL, so that from the
ontology we can automatically create very powerful queries. See
http://www.intertwingly.net/wiki/pie/PaceSparqlLink . These queries
go beyond what XQuery can do. It is a lot easier to mashup
information from different sources, since we are not tied to a
complex document structure. To work with XQuery correctly you need to
understand the semantics of the document. But to do that you will
need to find and read the complex documents that describe them.
All this and a lot more is what would make the Atom Application
Protocol a lot simpler, a lot more general and a lot more powerful if
it were to take RDF seriously. APP could specialise in being a
protocol and avoid having to define new mime types and xml formats.
Reality is extremely complicated already. If you don't start with the
simplest possible mathematical structure complexity will kill you
very quickly. That is why I stated that REST is not enough by itself.
You need to take URIs as seriously as RDF does (The R in RDF stands
for Resource). And you need extreme clarity.
By contrast when I look at XML I find numerous practical
applications; and people getting work done while ignoring the
philosophy. It's not that the philosophy isn't important; but
philosophy without practical application is mental exercise at best.
The best xml application use it as a mark up language which is what
it is. I am thinking of xhtml and open document formats. These are
huge improvements over what came before. In this area xml is king.
XML can form a serialisation of RDF, though the current one (RDF/XML)
is sadly not good enough for xml people, and makes it look like RDF
is a lot more complicated than it really is (it is simpler than xml).
As far as data formats go though I would say again that the SOAP
experience is revelatory. SOAP did not understand REST in 2 ways:
- It tries to wrap the HTTP layer in xml
- The data format itself does not take the URI as far as it can go.
RDF + REST is what is needed. Nothing less will allow us to deal with
the huge complex phenomenon of the world in a tractable manner.
Henry
--
Elliotte Rusty Harold [EMAIL PROTECTED]
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/
cafeaulaitA/
