[For the basics of R3 syntax, see the R3 Draft.]

One of the primary things which makes semantic markup useful is that it allows inferences and deductions based upon knowledge. For example, if I know that John is the father of Susan, and Greg is the brother of Susan, then I can create semantic rules like this:

  A brother is a male sibling
  The father of a sibling is the sibling's father.

and deduce from these rules that John is Greg's father.

R3 allows for these kind of relationships to be expressed through using special nodes that are known to belong to an ontology schema. R3 syntax remains exactly the same except for the introduction of a <template/> tag, which defines spaces for placeholders which need to be filled in accordance with certain critera for a relationship to hold. For example:

[Read my earlier post to understand why I object to RDF/XML, and the need for this replacement.]

R3 is an RDF dialect that is intended to be an isomorphic replacement for the RDF/XML dialect. In addition to the base syntax, R3 may be extended to allow inferences and relationships to be drawn on the basis of class (an alternative to the W3C Web Ontology Language (OWL)).

While a RELAX NG schema is planned, at present the language is primarily defined through a series of examples:

RDF stands for Resource Descriptor Framework, and is a cornerstone of the Semantic Web as envisioned by Tim Berners-Lee. The basic idea of RDF is very simple: it describes a series of linked objects of the form Subject -- Predicate --> Object. For example, John -- owns --> a Cat.

For the last nine years, Tim has been championing XML and RDF as the solution to the Semantic Web problem.

Yet despite the Web becoming so pervasive that it is almost impossible to imagine living without, the Semantic Web remains a distant dream, and RDF a niche technology known about only by a hardcore few. So what has gone wrong?

Although very verbose, The REST dialogues discusses why the REST paradigm provides important benefits when writing web applications, and how SOAP and/or RPC web applications can be rewritten to utilize REST principles. It's only up to Part 3 (of 9) -- I'm going to keep an eye out for the next one!

On much the same note (but much shorter), S stands for Simple pretty concisely sums up why I don't want to touch SOAP with a 20 foot pole.

This just seems like common sense to me. But I see people building applications that break pretty much all of these rules all too often. Whatever happened to be liberal in what you accept?