Stefano brought N3, or Notation 3, to my attention – it’s a good thing!
I hate XML. It’s a mess. Wrong on so many levels. But getting the industry to switch is now nearly impossible. XML has played almost all the cards you can to make a standard sticky and lock-in users. For example it’s extreme complexity. Just like that of the Window’s API. That makes people extremely reluctant to abandon their sunk costs after learning it.
That said I keep hoping that something better will emerge.
One possibility is that something will emerge that provides overwhelmingly improved UI. Making users smile can be a powerful force for change. So cool UI might be the lever. Things like SVG and Lazslo are examples of folks making a run for this exit. On a lesser scale the evolution of HTML/Javascript just keeps on hill climbing.
A less plausible possibility is that we will all rendezvous around one standard from for storing our documents, our data. This idea has been a fantasy of the ivory tower crowd since beginning of time. There has been a cool up and coming normal form at every stage of my life. I still have some stacks of punch cards. I wrote programs to convert IDL databases into suites of prolog assertions. I can’t count the number of times I’ve forced some data structure to lie down in a relational database or a flat file that sort/awk/perl would swallow.
After a while one becomes inured to hearing the same tune, the old enthusiasm returned again new clothes. You wish them the very best of luck because of course you remember how hopeful one once was that this could all come together. As a result I’ve have been treating the Semantic Web work with a kind of bemused old fart’s detachment.
But! Step past all the self indulgent ivory tower talk of one world data model. Skip the seminar on how soon we will compute the answer to everything. You don’t need to know from reification, or Mereological Ontological.
This stuff is actually useful.
Look at this:
:dirkx foaf:based_near [
a geo:Point;
geo:lat "52.1563666666667";
geo:long "4.48888333333333" ].
That tells us where something named here as :dirkx is lives. That’s it! No wasted tokens. Easy to parse. That’s why I like N3. Easy for humans, easy for computers. XML is neither.
<foaf:based_near>
<geo:Point rdf:nodeID="leiden">
<geo:lat>52.1563666666667</geo:lat>
<geo:long>4.48888333333333</geo:long>
</geo:Point>
</foaf:based_near>
XML is good if your getting paid by the byte.
I’d love to see XML displaced by something more practical. Something that lowers the barriers to entry so that you don’t need a few meg of code just to fool around. I believe that XML’s complexity is good for large players and bad for small players. I want to see the small players having fun – and frustrating the large players.
N3 is neat, but what about RDF?
RDF is just fine. You need to clear way all the overly serious ivory tower presentation. get past all that righteous marshmallow fluff and down at the core you find a nutritious center of practical and simple useful good stuff. How nice! It’s going to drive the marshmallow men in their tower crazy if this thing takes off!
When I look at RDF I notice two critical things. It is much easier to stack up new standards in RDF than it is in XML. Look the example above. It’s using a standard called geo and one called foaf. Click on those links to see how straight forward they are.
In XML if you want to define a new standard it takes extremely talented labor. Only a handful of people can both understand XML Schema and think in practical terms about real world problems. In RDF any fool can do it; which means that anybody with some data to move can get on board without having to go thru some gauntlet of heavy industry standardization.
The second thing I notice about RDF is actually a blind spot.
Above I mentioned two ways that XML might get displaced. One on the supply side (data normal form) and one on the demand side (presentation). There is a third – data exchange. Exchange is where the powerful network effects are – always! RDF is better for data exchange than XML. It’s easier, it’s simpler, and it is far better for layering, mixing, and creating new standards.
This trio, and the standards around them, are key to making anything happen in the net.
- Supply: writers, data, storage, normal forms, etc.
- Demand: readers, presentations, ui, etc.
- Exchange: messaging, subscriptions, polling, push, etc.
The RDF folks think that the demand side is where the leverage is. That’s wrong. Content is not king! Exchange is king. In the world of ends, the middle rules.
Pingback: captsolo weblog - Daily links
But if n3, xml or rdf are all so structured and contextualized it should be trivial to convert between them no?
It’s a little like saying that there is no difference between deciding to learn Portuguese v.s. Chinese since yeah you can always get a translator. The question is what pool of complements you get to draw upon. The wealth of compliments appear around the exchange – so if all the exchanges of data are rendered in XML then XML will have all the complements and all ways of normalizing your data will become subordinate to that. It’s a very highly leveraged choice point in the nature of what our data models will look like for the rest of history; but also a highly leveraged choice point as to how damn hard it is to do even the simplest of things. XML success means we are stuck with a foolishly complex data model, one encrusted with vestigial organs from ancient standards battles, and a very high barrier to entry.
Well, if there’s 100% fidelity in the translations (or damn close), I think that weakens the Portuguese vs. Chinese argument and backs Mike’s position. In the extreme, the simpler approach becomes an authoring tool for the accepted standard. Then a generation later, someone else tears down the whole edifice.
I would prefer to just assume that your translator is perfect and instead point out that 890 million people speak Mandarin (Chinese) and only 180 million speak Portuguese. What does that say for the survival of Portuguese as a language in a world where barriers are evaporating? If RDF/notation-de-jour fails to be used to exchange then it’s will be marginalized into irrelevance.
The oh we can translate back and forth is self delusion on the part of the subordinate exchange protocol and it is dismissive on the part of the dominate one. The argument that “a generation later” does little to may my life better, eh?
My point is that if you dislike XML as a data exchange notation then RDF/N3 offers you a chance at something substantially less obnoxious for filling the role of default language for data exchange. “Generation” is exactly right though; as I point out here:
YAML is the only thing that I’ve seen in the last times that could conceivably replace or complement XML.
RDF is not a replacement for XML, in fact, RDF is not a syntax, it’s a model, which has XML as its “primary” serialisation syntax. N3 or Turtle are (IMHO) both better for authoring than RDF/XML, and converting between them really is not a problem – I know, I do it almost every day…
XML is great for data interchange due to the fact that it has handled all the encoding and i18n issues once and for all. True, it’s verbose, and RDF/XML perhaps even more so, and thus some people are working on binary XML.
As for the point on demand/exchange, I think you’ll agree that without demand there won’t be any reason to do exchange. Also, RDF is designed specifically for exchange, it’s the whole point of the underlying model, being able to merge (and emerge!) data from disparate sources.
This post is filled with so many things that I just can’t believe anyone else believes that I’m starting to doubt your seriousness, I’m to the point of wondering if even the first sentence is true:
“Stefano brought N3, or Notation 3, to my attention – it’s a good thing!”
Anyway, let’s go through the points:
1. “Things like SVG and Lazslo are examples of folks making a run for this exit. ” huh? Xml based dialects are examples of folks making a run for an exit from xml? can you clarify what you mean by the UI exit in this context?
2. “XML is good if your getting paid by the byte.” xml’s utility for me is it’s ability to switch between data centric structures and document centric, I’m not sure if one would find a document format in notation 3 very helpful, that said I happen to prefer passing around JSON serialized xml data to save on bytes, but I think that is generally a minor consideration.
3. The foaf example, right, that’s fantastic, a particular dialect based on RDF serialized xml shows why xml is neither human nor machine comprehensible. RDF has problems for human comprehension of marked up true, let’s suppose a non-namespaced xml instance of the same data:
<isNear>
<point id=”leiden”>
<latitude>52.1563666666667</latitude>
<longitude>4.48888333333333</longitude>
</point>
</isNear>
I would be willing to accept that Notation 3 syntax would still be preferable, but the difference between them is no longer so great. The RDF/XML markup was annoying and incomprehensible for a human because of the the various namespace prefixes, humans have problems reading namespaces (by humans I mean people without a great deal of experience reading namespaced xml) a human typically understands an instance as being all in the same problem domain, namespaces assert that data is in different problem domains, and that confuses us (this argument here is not very developed, basically because I don’t have the time to go into it, sorry). Also the use of namespace qualified attributes has been shown to often confuse people. even those who are reasonably familiar with the usage of namespaces, so basically I find your choice of an especially complicated and ugly example of xml as a basis for arguing that xml is ugly and complicated about as convincing as taking the a picture of the fattest living american and arguing that americans are overweight.
4. “It is much easier to stack up new standards in RDF than it is in XML.”
This seems to be some sort of argument for the usefulness of RDF Schema. pointing at the geo was probably a good idea, because it seems comprehensible with a cursory glance, however the FOAF schema looks just as irritating as XML Schemas it has been my displeasure to see.
5. This leads us to the next point: “In XML if you want to define a new standard it takes extremely talented labor. Only a handful of people can both understand XML Schema and think in practical terms about real world problems.”
There is no obligation in xml to define standards via XML Schema, this may be considered by some people to be the kind of pedantic statement similar to that of the RDF folks who are always saying “RDF is not XML!” when RDF as xml is all anyone seems to be interested in – in that it sometimes seems that all people are interested in is defining xml standards with XML Schema, that however is an aberration that I believe has just about run its course. Xml schema, given its limitations, tends to spread the design of ugly XML. And it is hard. So it seems to me that what you really dislike is XML Schema. Me Too! 🙂
6. “RDF is better for data exchange than XML. It’s easier, it’s simpler, and it is far better for layering, mixing, and creating new standards.”
okay, well here are some problems I have with RDF exchange, these are no doubt caused by my understanding xml better than I understand RDF:
a. When I get some RDF data (in xml let me note) the document element is RDF, the namespace is RDF, there are a number of other namespaces I might or might not understand, however there seems to be no way for me to understand what is the primary purpose of the instance I am getting (perhaps you know of a way). Is it FOAF, is it RSS, is it whatever? The primary purpose of an xml document is in most instances determinable by its namespace qualified document element (of course it is industry habit to only have one child of the RDF element and I suppose that this is then element that defines the primary document purpose, but this is I believe not required behavior), this means that one can have a generic xml handler that passes off instances to a process dedicated for each qualified document type and catch errors in cases where a qualified document type is unknown by calling a generic xml handler.
In writing such a generic xml handler last year I found that one could reason about the nature of a document by various design pattern used, it is very difficult to do reasoning about RDF documents by examining design decisions (for me at any rate) because RDF constrains the design decisions. Perhaps there are RDF design patterns that I am not familiar with however.
Because of the difficulty I faced about reasoning about RDF/XML instances, and because of my need to have the system accept all xml instances, I finally did the following, of passing the RDF/XML off to a generic handler which had some generic RDF graph functions, which then compared the namespaces found in the document against a list of RDF namespaces known by the application, and informed the user which namespaces were ‘in document’ and understood by the application, giving the user the opportunity to choose to reanalyze the document as belonging to a particular namespace. (I later added this as a generic capability to xml instances as well)
note that in the case of RDF namespaces we encounter helper namespaces more often than we do in xml (at least it seems like this is the case to me), the geo namespace is a helper namespace for RDF documents such as FOAF documents or RSS documents, whereas in xml namespaces seem to exist most often as document types in themselves (example xmi), I am of course aware of various exceptions, the xml namespace, dublin core, xlink etc. but the prevalence of helper namespaces seems greater in RDF. Perhaps others would argue against that.
It should also be noted that RDF has sometimes been used as a helper namespace for xml documents, layering a graph over the document, which is also a common usage for the xmi namespace. I think this a reasonable use of RDF.
So from my own experience I find RDF less useful for exchange (except as a helper namespace), definitely less easy to develop new formats in, and, surprisingly, less easy to reason about generically.
okay, I should really get some work done now.
Pingback: captsolo weblog
I was thinking about reverse polish notation. Why not just use its postfix notation. So the example becomes:
52.15
geo:lat
4.49
geo:long
dirkX
foaf:based_near
or
52.15
enter
4.49
geo:Point
dirkX
foaf:based_near
Here’s another example from w3
pat
enter
bio:human
is pat is a human
Pat Smith
per:name pat is human and named Pat Smith
Patrick Smith
per:name pat is human and named Pat Smith and Patrck Smith
Rover
enter
bio:dog
is rover is a dog
per:pet pat is human and named pat smith and patrick smith and has a pet dog rover
You could have a little sort of gui calculator interface with operators loaded in from the namespaces. Does that make any sense – my wife is racking up the dominoes so I got to go 🙂
when Danny says:
“Re. the point bryan made regarding knowing the purpose of a document – strictly speaking, the situation is actually the other way around. The root-element namespace check only works in XML because 1. XML tends to be hierarchy-oriented and 2. people don’t do the same kind of data-mixing you see in RDF. It’s not that the problem is solved, it’s just that people aren’t running into it (yet, maybe never).”
I would refer to my
“The primary purpose of an xml document is in most instances determinable by its namespace qualified document element”
which I meant to take into account that while this behavior is industry wide it is not specification defined. However it is industry wide and I don’t think I’ve ever seen a situation where the document element was not aligned with the purpose of the document, actually now that I think of it I’ve made some borderline cases for my application, such as <xmlWrapper type=”Docbook”>
<title>some title</title>
</xmlWrapper>
which was a wrapper for fragments of another xml instance, generated by running an xpath query over a file ( obviously there was more information than that in the wrapper, such as location of original xml file etc.) one might argue that the purpose of such an instance is not the wrapper but the purpose of the fragment of the document wrapped which is how I interpreted it in my system.
Of course what I did, and which I think most people do when faced with this problem (given that I have seen variations of it over the years) is to have a namespace qualified attribute on document elements specifying the type of instance this is an example of. If the attribute is missing it defaults to the document element, in this way I was also able to specify that an instance was FOAF at first pass, although of course instances imported from outside never had this attribute and I had to use the namespace analysis method discussed before for those.
This of course necessitated various other hacks to off-topic to discuss here.
“But RDF *does* allow you to type documents (and I don’t mean into Word) because they can be referred to as resources (internally with rdf:about=””)”
is this what it is used for? exclusively? is this presumed to be a rdf:about on the document element? (in xml cases of course, as that is all I’m interested in)
If we are going to put an entire science like geology or botany onto the semantic web we need a really easy vocabulary for non-programmers to understand what is going on, how the model can grow organically, and what establishes trust, etc. The N3 flavour of RDF seems to be close to delivering. However there does not seem to be a clearly written rough guide to RDFS terms with examples that are relevant to a hierarchical data structure that would show non-nerds how it might all fit together.
Pingback: Internet Alchemy