Last Call comment (ISSUE-77) : default blank node generation in the header

(Harry, my apologies, I forgot to add the WG on the cc line in my previous mail. Please ignore that one. Ivan)

Harry,

This is an official response from the RDFa Working Group concerning your comment recorded as ISSUE-77: Adding in extra blank node default subjects

http://www.w3.org/2010/02/rdfa/track/issues/77

Your comment says:

[[[
Adding in extra blank node default subjects as a feature of RDF Profiles vocabularies, i.e. to make vocabularies like OGP produce valid triples. Note that in some instances of RDFa processing the profile is retrieved anyways, so might as well make it do very useful things.
]]]

which, if our understanding is correct, means that a profile document would also be able, beyond the specification of prefixes and terms, to modify the processing steps of RDFa insofar as, under specific circumstances, new (blank node) subjects would be generated into the resulting graphs for specific predicates. The Working Group discussed this on its telco, but found several problems.

First of all, for the specific use of Facebook, we are not sure that this would solve the more general problem. As far as we can see, one of the problems with the Facebook deployment is that its user base does not include namespace declarations in the HTML code. Recognizing this issue, and also in response on another Last Call Comments of yours, the Group decided to introduce the concept of default profile which may (if Facebook agrees) include the og prefix. However, using the mechanism you describe would, nevertheless, force Facebook users to refer to a Facebook specific profile that they would forget just as often as they forget namespace declarations today. Of course, one could imagine further Facebook-specific control mechanisms to be included into an overall default profile for RDFa but we are not sure that would be appropriate for a profile that is to be used by any RDFa content on the planet.

The second, independent, and obviously more important issue is that this proposal would require is mechanism and a specification whereby the behaviour of the RDFa processor could be controlled dynamically. Ie, the processing steps as described in the RDFa specification would have to include a number of "hooks" for adaptation, and those hooks could be used by a declaration in a profile file. It is certainly an attractive idea, but the Working Group feels that the detailed specification of this feature and the implementation requirements, would be way too complex for RDFa at its present stage. As a consequence, the Working Group decided to close this issue without adding this feature.

Thank you for your feedback on RDFa Core and for your continuing input into the RDFa Working Group. We have attempted to address your concerns with this issue to the best of our ability.

Since this is a Last Call issue, we ask that you please respond to this e-mail and let us know if this solution works for you.

In the name of the RDFa Working Group

Ivan

This is to close ACTION-77

----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf





----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf