XML is dead. Long live RDF?

I'd choose concept over implementation any time. I kinda always knew that, but I rediscovered this recently. I want to be able to confide in that and in my intuition. It tells me XML is dead. Really. So here goes.

At XML Prague 2013 it occurred to me that RDF means the death of XML. I was discussing RDF with +Manuel Lautenschlager, and at one point he said: you can just infer XML. I tried to get him to elaborate on this statement, but we didn't seem to agree on the implications. But I thought, if one successfully manages to reason about the format of data, then XML would be one of the possible outcomes. This doesn't just mean that XML could be a subset of RDF, but conceptually: XML, its media type and any knowledge about it could simply become part of an ontology.

I discussed this with +John Snelson, who wasn't impressed. According to him, RDF is too fine-grained to present itself as a tree, the serialization would not be performant, and implementing the concept would be more complicated and time-consuming than just using XML. I'm not sure if he rather supports the possibility of embedding XML in RDF, as proposed by his MarkLogic colleague +Charles Greer, who held a talk on the subject. John thought the idea might be interesting in theory, but would not go into practice. But I feel that his approach is still a bit too techie. Data is just data, and if it weren't for concepts developed over the past decades we would still be punching holes in cards. Of course, I wholeheartedly agree that when it comes to computer science, the only way progress can be made or will even occur is when a thought is put into practice, and solves some real-world problem. But in this case, I think Manuel may have had a point, whatever it was.

Yes, for now I see that we shouldn't "infer XML", but the problem of using HTML, XML, RDF and JSON together and at what moment remains a issue. Particularly for myself, because I have a lot of room to experiment and choose the best solution at any time. From an eagle-eye perspective, the world of data just doesn't seem so complicated as to need all of them. Personally, I'd rather loose some things along the way and go back to pick them up again, then to stay put and juggling formats all the way till the bitter end.

Do I really need HTML? No. I need some way to tell a machine: this is a rectangle, this is a bitmap, this is a font rendered at this size and at that location. This you can click and it screams at you, this is just sitting there and will shift like sand when I try to resize it. Do I need XML? Do I? Sometimes a user wants to see what he's actually doing. He wants to see the under-water-screen and understand it. Why deny that? Anyone can understand and write XML (as long as it has no namespaces). Do I need RDF? We all do. We need to finally understand that the world is about local knowledge and conventions. It's the only way we can improve upon the WWW and fight the googly-eyed monster. Do we need JSON? Probably not. We need a way to transport a construct of every-day datatypes we use in our programming language. We're just very lucky JavaScript looks as it does, and I wouldn't for the life of me go back to PHP.

Since JavaScript took off, a lot of worries have faded to the background. But recent ideas like moving RSS to JSON tend to become a little like using a hammer for everything. Just to recap: data is still just data. More and more I get something like: who cares? We'll keep on blogging about the advantages of this over that, and meanwhile the world keeps turning. The main message is: the concepts are much more important, and they are: relations versus multidimensional arrays. Someone told me some time ago he would represent graphs in trees no matter what, just for the sake of having a user interface that can be navigated in a traditional way. And only now I see that, yes, so should I. So we have come to a full circle...

Trees are dead. Long live graphs. In the form of trees.

Comments

Post a Comment

Popular posts from this blog

Abandoning hope... and XForms

Sometimes a decision must be made. I have invested many hours in a standard that is quite complex and tedious to maintain, and that was great fun, but enough is enough. Why did I invest in XForms when it took so much effort and time? Because I believe standards are good and good standards come from the W3C and the XML community. Also, I always had somewhat of an inferiority complex in IT development that I tried to compensate by using techniques supposedly invented for common folk, i.e. non-programmers. Both are bad reasons from where I now stand. I took up XForms because I was infected by the enthusiasm of a friend (who was even quicker to abandon it) about 3 years ago. At first I assumed it just used a model from which to infer a form. It turned out it was like a superset of HTML forms with options for displaying and validating data. This was largely taken up by HTML5, as we all know. The Model remains the core of XForms, but the W3C is slow to respond to innovations and the need f
Read more

JS Journey into outer space - Day 5

This article was written as part of a knowledge sharing program I created for front-end developers. It builds up to creating reusable abstractions by studying async transducers. Day 5 It's time to add more operators. We already have map , but what if the mapping function returns another "container" value, like an array or observable? 🦉 In RxJS some operators like switchMap , concatMap , or mergeMap will expect a "project" function that returns an observable (or promise or array), but what happens then? First map is applied with the project function and after that the result is "flattened". In other words: when the returned (inner) observables emit, the mapped (outer) observable emits those values instead. Since RxJs streams have a specific async behaviour the flattening process takes concurrency into account: mergeMap will flatten inner observables whenever they complete, regardless of the order, but concatMap will preserve the order of the ou
Read more

JS Journey into outer space - Day 4

This article was written as part of a knowledge sharing program I created for front-end developers. It builds up to creating reusable abstractions by studying async transducers. Day 4 Now we have modified transduce to handle async it's time to figure out how it can handle observables. Kickoff 🏈 First we need to pass the onNext function which kicks off the callback chain. In RxJs this is called subscribe instead, so let's rename the parameter and the callbacks to be more in line with RxJs : function transduce ( input , fn , subscribe , onError , onComplete , init ) { subscribe ( input , { next : ( cur ) => { init = fn ( init , cur ) ; } , error : ( err ) => { onError ( init , err ) ; } , complete : ( ) => { onComplete ( init ) ; } } ) ; return init ; } ; 🦉 Observables are considered a push-style of dealing with many values, while generators are pull-based. In
Read more