Drupal, RSS/Atom, HTML5 points (was: meeting record: 2009-01-22 RDFa telecon)

On 22/1/09 18:34, Ralph R. Swick wrote:
> The record of today's RDF-in-XHTML Task Force telecon [1] is ready.
>
>    [1] http://www.w3.org/2009/01/22-rdfa-minutes.html

I'm never sure how best to respond to points from these minutes. Here 
I've kept it in one mail but changed the topic. I suppose topic could be 
refined further if any of these themes/threads gets discussed. --Dan

comments intersperced below -


>     ACTION: [WITHDRAWN] Manu write the perl code for Slashdot. [recorded
>     in [20]http://www.w3.org/2008/09/11-rdfa-minutes.html#action11]
>
>       [20] http://www.w3.org/2008/09/11-rdfa-minutes.html#action11
>
>     Manu: I've spent some time on this and it looks like a lot of work
>     ... Slashdot doesn't generate clean HTML4
>
>     Manu: I don't want to have to fix all their templates; it will be a
>     large patch that they may not accept
>     ... I won't have the time to generate this massive patch
>     ... would need more buy-in from Slashdot
>     ... I think I've done as much as I can
>
>     Shane: Slashdot is an interesting community but it doesn't really
>     affect the broader community
>     ... Drupal on the other hand would affect a broader community and
>     makes more sense for our attention
>
>     Manu: Wordpress would be another likely candidate

+1 On supporting Drupal here. Of all the candidates, I think they make 
most sense, in terms of reach into the world, buy-in from highups, etc. 
Wordpress has similar reach but I don't think those leading the work are 
as enthusiastic as the Drupal guys. So supporting them in their decision 
to try RDF/SW would be great.

The comments in http://groups.drupal.org/node/16597 show things are 
progressing along. It's not entirely an RDFa thing (more like D2RQ/R2R2, 
but I'd love to see some work at wrapping SPARQL around the data Drupal 
keeps in SQL too).

FWIW I'm running (largely un-used) XHTML RDFa templates on a Drupal 
installation at http://www.foaf-project.org/


>     ACTION: [PENDING] Ralph think about RSS+RDFa [recorded in
>     [26]http://www.w3.org/2008/09/11-rdfa-minutes.html#action15]
>
>       [26] http://www.w3.org/2008/09/11-rdfa-minutes.html#action15

While you're thinking Ralph, may I try to persuade you that Atom+RDFa is 
where most value/energy/attention is going currently. Everyone lost the 
RSS wars, but Atom isn't so bad.

eg. SearchMonkey uses Atom+RDFa - 
http://developer.yahoo.com/searchmonkey/smguide/faq.html
Just to confuse us, they call it DataRSS - 
http://developer.yahoo.com/searchmonkey/smguide/understand_datarss.html
http://developer.yahoo.com/searchmonkey/smguide/datarss.html

In the Open Archives scene, the ORE spec seems to be juggling some 
choices amongst XHTML, Atom, RDFa etc. - 
http://www.openarchives.org/ore/1.0/http ... (rather than pre-Atom RSS).




> Feedback on RDFa from WHATWG/HTML5
>
>     ->  [27]Discussion with Ian and Henri about HTML5+RDFa (part 1/2)
>     [Manu 2009-01-19]
>
>       [27] http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Jan/0075.html
>
>     ->  [28]Discussion with Ian and Henri about HTML5+RDFa (part 2/2)
>     [Manu 2009-01-19]
>
>       [28] http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Jan/0076.html

I also had some discussions with Henri and with Ian this week. 
Separately, mostly in 1:1 IRC, with a little in #whatwg on irc.freenode.net.

In both cases too, I think things were quite constructive. I talked more 
with Henri. We found common ground around the idea of identifying and 
testing a subset/profile of RDFa that doesn't use any form of URI 
abbreviations. It seems most parsers can live with this, so long as the 
monstrous hack of 'xmlns:http="http"" is used; without this, they all fail.

My test files and rough results are in 
http://svn.foaf-project.org/foaftown/2009/rdfa/tests/readme.txt ... I 
didn't pursue more than two test cases (t6 and t7), since I expect it'd 
be better to have such things done thru the real rdfa test harness. But 
from looking at 5 or 6 parsers, it seems the xmlns:http is needed.

As Manu mentioned, Henri has even made an option for checking this 
profile of HTML5+RDFa-namespace in validator.nu. This is something I'm 
very very pleased to see. While namespace-free RDFa may be verbose, it 
is healthy for copy/paste scenarios since it doesn't depend on context 
higher in the document.


I talked a bit with Ian. He popped up unexpectedly in IRC to ask me a 
bit about RDFa and my expectations for who would write it. We talked a 
bit about where it would live on the complexity scale, ... authoring 
versus copy/pasting, and on how such scenerios would affect the best 
choice of metadata syntax. My take is that it's up near Javascript and 
CSS when it comes to actual authoring, but many common idioms will be 
copy/pasted either in their entirety, or with bits of template that are 
filled in.

Ian repeated his request for use cases that don't have a built-in 
presumed answer of rdf/rdfa. I suggested we might turn to scenarios from 
the SW lifesciences community here (maybe egov too?), and go investigate 
what those end user publishers and content creators and organizations 
are hoping to see from future HTML metadata options, and see if RDFa use 
cases fall out of their needs. I know folk on these lists see this as 
revisiting old ground, but I suspect it could be a productive route for 
all of us.

Ian also asked about how we describe images in RDFa, eg. repeated 
properties of the image from some <img>. As far as I can see we don't 
have a particularly great set of options here, but that's life. I'd 
welcome a pointer if anyone has a summary of the idioms/choices (eg. 
repeat the URI in an @about; use inversely named properties like 
foaf:depiction, or maybe @rev for non-literals).

>     Manu: there was less opposition than I'd expected
>     ... but demonstrated use cases are important
>     ... may need to assume less familiarity with RDF when describing the
>     use cases
>     ... details of RDFa aren't familiar to most folk I've talked with;

Yup. We get the same on Dublin Core discussions sometimes, reasonably 
enough.

eg. "So, ... let me get this straight? there are resources and literals, 
... and literals are, kinda, resources, since all things are 
resources... but you can only write an RDF statement about a non-literal 
resource, ... but the statement can be saying that it's the owl:sameAs 
thing as some literal?" (etc...)

>     CURIE seemed to trigger most concerns

Yep. Same with discussions on the mailing lists in my experience. 
Dislike of namespaces is the one thing that seems to bind together many 
members of the XML and WHAT-WG communities :)

>     ... Henri Sivonen said he'd be willing to accept RDFa if it dropped
>     CURIEs

I really think it's worth exploring this profile. Is there *any* 
reasonable re-reading of the XHTML+RDFa spec that would allow us to get 
away with full URIs everywhere, without requiring xmlns:http="http" ?



> Finalize behavior of @prefix
>
>     Manu: we've talked about splitting @prefix from the token
>     specification mechanism
>     ... Ivan says he sees @prefix as an analog to @xmlns
>     ... Mark has suggested that where @prefix is used (HEAD or BODY)
>     could be significant
>
>     Mark: one of the problems with the simple analog is that this forces
>     us into the simple hierarchical model
>     ... a long time ago there were discussions with (Reuters?) about
>     using RDFa
>     ... one of their use cases was documents, especially small ones --
>     consider a twitter post -- that may require lots of namespace
>     declarations
>     ... would like an xinclude-like mechanism
>     ... there's currently no way to use xinclude for this
>     ... so simple analogue doesn't offer a solution
>     ... I suggest that people may consider documents to be like
>     programming languages; HEAD is an initialization section
>     ... an alternative is to say that prefix declarations _only_ are
>     done externally; @profile works like this
>     ... so the declarations apply to the entire document

Another approach would be for parties who want to minimise ns 
declarations (eg. Reuters) to have a flattened, monolithic namespace. 
Something like a tinyurl / purl approach, where eg. an HTTP 301 / moved 
(?permanently) response could point back to the 'real' property or class 
URI. I'm not sure if this one would fly but it may have appeal in 
certain quarters, eg. where content creators want to keep some 
independence from the exact choice of namespaces being used. Simple 
parsers might output the homogenous (flat ns) triples; fancier ones 
might do the mapping and add or replace with the full collection of long 
ugly URIs. Ok this is offially thinking-out-loud now, so maybe I'll stop.


cheers,

Dan

--
http://danbri.org/

Received on Thursday, 22 January 2009 18:37:08 UTC