The principal discussion point this week was the relationship type to be used on a link element pointing to a DR and what should be returned to a user agent following such a link. This follows the discussion held in Boston last month
where Tim BL argued that we should use a link element such as
<link rel="meta" type="application/xml+rdf" href="..." />
This should return triples that have the resource as their subject and, perhaps, a link to the full DR. In other words, server-side processing would support existing RDF clients. This creates a minimal barrier to adoption from a client perspective.
However, it contrasts with the way the group has been thinking so far which is to define a relationship type of 'powder.' Following such a link would return one or more DRs.
The problem is this - if we use the generic rel="meta" system then it's quite possible that the metadata would be extensive - and possibly largely irrelevant to the particular context. How can you get just the data you want? As much as requiring server-side processing presents a hurdle to adoption by content providers, requiring client-side processing presents a barrier to user agent adoption, especially in the mobile market.
Somehow we need to make sure that the processing is minimised and always relevant to a particular context - is <this> mobileOK? Is <this> child-safe? These look a lot like potential SPARQL queries? Yes - so maybe we should encode the SPARQL query in the href attribute? We didn't discuss this in detail but it is possible. However, there is a generally feeling that the original rel='powder' approach has merit. Given that we plan to specify not only the semantics of a DR but also an XML schema for it, clients could process the data in a variety of (optimised) ways in narrow circumstances.
One idea that was frowned upon was having two different representations of the same thing (i.e. and XML version that could be translated into an RDF version).
There's a lot of thinking still to do on this topic but it was good to air the issues.