Re: RDFa for Turtles 2: HTML embedding

Melvin Carvalho:

  This seems sensible.  I did have the idea of dumping a whole bunch of RDFa
> triples in the footer, and setting visibility to zero, but if you can do it
> safely in the head, problem solved!   We're back to the old days of putting
> meta data in the head of a document.
>
> This works for the rel attribute, but what about for property?
>
> One nice thing about RDF is that it's a set, so if you put a full dump of
> triples in one area, even if there's a dup somewhere in your markup, a
> parser, should remove duplicates.
>
>
Here's my take.  RDFa gives us a lot of choices.  Embedding in the HEAD,
embedding in a display:none DIV and closer embedding to the document text
are all choices somebody might take.  I want to develop a profile that works
with the widest range of RDFa tools that works with certain engineering
decisions and that is easy for document authors to understand.  I think
"RDFa Lite" formats will be a good stepping stone towards building the RDFa
ecology.

Practically,  my systems have long had a separate module that manages the
HEAD,  so that resuable modules with visual appearances can add style sheets
and Javascript includes to the document.  I've recently added a little
triple store to the HEAD manager so that it accumulates triples as the
document is rendered.  I'm sure there are other great ways to add RDF output
to an app,  but this approach separates presentation and content.

Anyway,  looking at your comment and at the docs,  I'd conclude that it
should be

#1 <meta property="{predicate}" content="{object}" />

I'm seriously conflicted about another possibility,

#2 <link rel="{predicate}" resource="{object}" >

I like "resource" better than I like "href" here,  because "resource" lets
us use a CURIE instead of a regular URI if we like.  This is very sweet
syntactic sugar,  but the cost is that existing HTML clients already know
what the "href" means...  Use of this isn't too heavy,  but I'd hate to
break RDF autodiscovery and the the apps that use it.

Towards that goal,  I think I'd just tell people to use "href" and write out
the whole URLs;  I've got a strong feeling that I want to give people "one
way to do it",  because I think this improves the odds that (i) people read
the docs,  (ii) follow the instructions,  and (iii) do so successfully.