- From: Ivan Herman <ivan@w3.org>
- Date: Thu, 3 Mar 2011 13:34:57 +0100
- To: nathan@webr3.org
- Cc: RDFa Working Group WG <public-rdfa-wg@w3.org>, Shane McCarron <shane@aptest.com>
- Message-Id: <8278C571-CD7D-41C4-AE80-8C04336E4415@w3.org>
On Mar 3, 2011, at 12:54 , Nathan wrote: > Hi Shane, All, > > I've just been preparing the LC response for 76, and there are a couple of bit's we've missed in the editorial changes - in line from here: > > RDFa Working Group Issue Tracker wrote: >> (Ed) Section 2.2 Examples: When profiles are first introduced here, I think it would be helpful to: >> (c) be explicit about the assumption of content negotiation of some kind that means that requests to http://www.example.org/vocab-rdf-dc will result in the RDFa document at http://www.example.org/vocab-rdf-dc.html > > The profile example here says: "The following (mythical) example RDFa Profile document, with a URI of http://www.example.org/vocab-rdf-dc.html" and then the "Using @profile..." example following has: > > <p about="http://www.example.org/doc" > profile="http://www.example.org/vocab-rdf-dc"> > > Which raises Jeni's question, could we align the two URIs? note that the full .html URI is also used in section 8.1.1 and 8.3.2 - so I'd suggest we simply change the quoted example to be .html too. > That has already been made (by me) on the Overview-src file. >> (Tech) Section 4.2 Host Language Conformance says: >>> The Host Language may define a default RDFa Profile. If it does, the RDFa Profile triples that establish term or URI mappings associated with that profile must not change without changing the profile URI. RDFa Processors may embed, cache, or retrieve the RDFa Profile triples associated with that profile. >>> >>> Note: Host Languages are required to change the URI of their default profile if items are added or removed from the default profile document. The URI change is required to accomodate RDFa Processors that statically embed the terms defined in the profile. Host Languages are expected to change their profiles very rarely. >> Will this restriction cause problems for HTML5 + RDFa given that HTML5 says that the rel attribute may take values defined in http://wiki.whatwg.org/wiki/RelExtensions, which is not going to be static and may change very rapidly? Or will the profile for HTML5 set a default vocabulary and thus possibly interpret NMTOKENs that should be ignored as CURIEs? > > sanity check, we're not going to define a default vocab for HTML5, and the default profile will specify exactly which terms should be picked up - correct understanding? > First of all, the default vocab for HTML5 and XHTML will be the same. At present, the profile file: http://www.w3.org/profile/html-rdfa-1.1 contains the HTML4 @rel terms plus some other terms that were used in RDFa 1.0. We still have to have the discussion on the exact content of the profile file(s) and their update mechanism, though, at the end of the day, this is not the RDFs WG's responsibility once it is out, but W3C's. For the HTML stuff I would try to rely on the HTML5 @rel mechanism, whatever that will be, but ruling out those terms that do not make sense in the RDFa setting. The generic default profile, that is also relevant for HTML, is http://www.w3.org/profile/html-rdfa-1.1 which contains almost exclusively prefixes. While I do not think there is an issue with the prefixes in the first table (W3C documents), the second one is of course to be discussed. I just put there some things that came to my mind but that is more as an example now rather than anything else Ivan > Cheers, > > Nathan > ---- 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
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Thursday, 3 March 2011 12:33:33 UTC