RDFa for Turtles

I'm working on linked data output for

http://ny-pictures.com/

so I'm trying to come up with an "RDFa Profile" that's appropriate for my
application;  goals are (i) separation of presentation in content (I can
move my <divs> around and never end up losing an "about") and (ii) high
compatibility with existing web browsers and applications.

Last night I was researching the WHAT-WG HTML 5 standards from metadata and
was pretty terrified,  and came out with the conclusion that we really need
a simple way to assert RDF triples that anybody can lose and that has little
impact on current server and client toolchains.

---------

Restriction:  All RDFa statements will be asserted in the <head> of the
document,  using certain patterns.

The patterns that will be used are

<meta rel="{predicate}" content="{object}" />
<meta rel="{predicate}" content="{object}" datatype="{type_of_object}" />

when we want to assert non-link properties about the current document

<link rel="{predicate}" href="{type_of_object}" />

for asserting link properties.  Now,  if we want to assert a property with a
different subject,  we can just write

<meta about="{subject}" rel="{predicate}" content="{object}" />
<link about="{subject}" rel="{predicate}" href="{object}" />

There's also a nice bit of syntactic sugar

<link rev="{predicate}" href="{subject}" />

when we want to make an assertion about which the current document is the
object.

My understanding is that this is a correct subset of RDFa that makes it
possible to specify arbitrary triples.  Am I missing anything?

I was initially worried about the lack of the name element on the meta
tags,  but a close look at the HTML 4 spec shows that the name is not a
required element.  I don't believe that this syntax is going to cause any
problems for mainstream software

------

So far I've been sticking to the letter of HTML and RDFa specs,  or at least
trying to.  Now I'm going to add

Requirement: Ability to embed RDFa in a document that is not,  globally,  a
valid XHTML document

There are two major reasons for this.  (A) the ability to create the web
experiences we want with standard markup is something that web developers
have long suffered.  Finally,  if you get your DOCTYPEs right,  you can get
fairly consistent rendering with five major web browsers.  If you use
XHTML,  you get less consistent behavior from current web browsers.

(B) Most conventional web toolchains (PHP,  JSP,  Cold Fusion,  Ruby on
Rails,  etc.) produce HTML by concatenating fragments of text.  In that
context,  it's almost impossible to verify that a dynamic web site is going
to produce valid XHTML under all circumstances.  Now,  you can build your
documents with real XML tools,  but that leads to a serious intermingling of
presentation and content:  it's hard to have a designer design a template in
Dreamweaver,  and it could require a rookie programmer hours to figure out
how to change a simple bit of text that is output by the application.
ASP.NET actualy does have a reasonable answer,  but it's pretty hard to get
anything else right if you use ASP.NET

Received on Wednesday, 10 March 2010 17:04:25 UTC