Search This Blog

Why Not a New Format?

Thinking about what is keeping RDF from wider adoption, I keep coming back to the fact that the serialization is, well, too complex. Why hasn't anyone stepped up to propose a XML syntax that plays well with the thousands of XML tools out there? Let the XML folk say, "I can for the simple syntax, I stayed for the powerful model."

The RDF people out there always chant, "It's the model, stupid!" Yes, indeed, and what a simple, powerful, and scalable model it is. It's certainly why people latch onto RDF. The model is RDF's selling point.

However, to get it adopted, it's the serialization that must be refactored. People are used to "Right click, view source", and the only way that will work in the semantic web is if the XML for RDF is simple and consistent and predictable. The fact that the same RDF model can be serialized into numerous different, yet semantically equivalent, is enough to drive anyone away. This is a serious bug with RDF and should be fixed.

The fact that I can't write an XSLT script for RDF/XML boggles my mind. There can no longer be a "RDF or XML" debate. That argument exists because XML proponents think in terms of tags and documents and schemas and DTDs. RDF/XML does not play in that world, and it is holding back RDF as a model.

Some might argue that RDF as model is the important part, not necessarily the syntax. "It's just computers talking to each other anyway" is a common cry. This argument forgets that the web took off because each and every user was able to see the source of the web page they were looking at. It was easy to cut and paste our way to mass adoption. Being able to look at a syntax played a major part in the success of the web. RDF needs this equivalent feature.

So my question is simply, why is no one at the W3C working on this right now? The next version of RDF needs to include a working serialization in XML that fixes the current bugs:

simple XML

consistent

validatable against a schema

predictable output of model

Maybe the better question is, how can I help? Is this on the W3C's plate?

Please, W3C, create a standard RDF serialization that elevates RDF as a first class citizen of XML. Everyone else has a schema, why can't we?

Popular posts from this blog

Now, this has to have a built-in somewhere in Scala , because it just seems too common. So, how to convert an Array to a List in Scala? Why do I need this? I needed to drop to Java for some functionality, which in this case returns an Array. I wanted to get that Array into a List to practice my functional programming skillz. **Update**: I figured out how to convert Arrays to Lists the Scala way. Turns out it's a piece of cake. val myList = List.fromArray(Array("one", "two", "three")) or val myList = Array("one","two","three").elements.toList The call to elements returns an Iterator , and from there you can convert to a List via toList . Nice. Because my first version wasn't actually tail recursive, what follows is a true tail recursive solution, if I were to implement this by hand. The above, built in mechanism is much better, though. object ArrayUtil { def toList[a](array: Array[a]): List[a] = { d

In which I port a snazzy little JavaScript audio web app to Dart , discover a bug, and high-five type annotations. Here's what I learned. [As it says in the header of this blog, I'm a seasoned Dart developer. However, I certainly don't write Dart every day (I wish!). Don't interpret this post as "Hi, I'm new to Dart". Instead, interpret this post as "I'm applying what I've been documenting."] This post analyzes two versions of the same app, both the original (JavaScript) version and the Dart version. The original version is a proxy for any small JavaScript app, there's nothing particularly special about the original version, which is why it made for a good example. This post discusses the differences between the two implementations: file organization, dependencies and modules, shims, classes, type annotations, event handling, calling multiple methods, asynchronous programming, animation, and interop with JavaScript libraries. F

In which the virtues of automated mechanical arboreal pruning are extolled over quaint manual labor, as applied to web development build processes. The setup Ever notice how the primary bit of marketing for many traditional web programming libraries is their download size? Why is that? Check this out: Why does size matter so much for these libraries? Your first instinct is probably, "because the more bytes you shuttle across the wire, the slower the app starts up." Yes, this is true. I'd also say you're wrong. The primary reason that size matters for these libraries is because traditional web development has no intelligent or automated way to prune unused code so you can ship only the code that is used over the wire. The web is full of links, yet web dev has no linker The web development workflow is missing a linking step. A linker's job is to combine distinct project files into a single executable. A smart linker will only incl