- From: Ivan Herman <ivan@w3.org>
- Date: Thu, 22 Jul 2010 10:44:07 +0200
- To: Shane McCarron <shane@aptest.com>
- Cc: RDFa WG <public-rdfa-wg@w3.org>
- Message-Id: <7AE86511-CD04-4147-8698-1F4286F08456@w3.org>
On Jul 21, 2010, at 18:25 , Shane McCarron wrote: > > > On 7/21/2010 6:09 AM, Ivan Herman wrote: >> Shane, >> >> for my understanding: this also means that there is no default @vocab value, neither in RDFa Core nor for languages, right? Ie, if, say, a term in HTML5+RDFa is _not_ defined in the magic @profile for HTML5, then that term is not recognized as a URI by default. >> >> (I am not sure how this fits in the policy the HTML5 group wants to take v.a.v. @rel values.) >> > > This is correct. And that is consistent with RDFa Syntax 1.0. As to the HTML5 group... I don't think they really care about triple generation and predicates. That's our bailiwick. Yeah, well... but we do care. If, in future, the @rel values will be generated on-the-fly by the community and that remains valid HTML5, can we allow ourselves to ignore that? > >> As for ':bla' type CURIEs: I do feel uneasy about the usage of an XHTML URI for these when using RDFa in, say, SVG. Any resulting URI would really be out of place there. I would be more in favour of what the RDF Workshop people called 'weak deprecation': we do not make statements on whether that would be removed in future RDFa versions, but we strongly advise the community not to use it... >> > > I think that for consistency with RDFa Syntax 1.0 we are okay requiring the use of the XHTML vocab URI for those special form CURIEs. I don't think it effects SVG at all. In that environment I would expect SVG to define a host language profile along the lines described below - with TERMs that would just work in rel="svgterm". But if, somebody, uses a rel=":svgterm" by mistake, that would suddenly go into the XHTML namespace. Ie, we should really say to an SVG author: please, do not use that! Ivan > >> Ivan >> >> >> >> On Jul 21, 2010, at 24:22 , Shane McCarron wrote: >> >> >>> Okay.... Thanks to Manu, I think that I have something new to propose that hangs together. The critical issue that we need to address here is how to handle TERMs in a consistent manner. Special rules for certain values of @profile or @vocab are just icky. Moreover, it is not extensible - and extensibility is what RDFa and CURIEs are all about! Here's a possible way forward: >>> >>> * Change our definition of TERM so that comparing an attribute value >>> to the current list of TERMs is *always* done case-insensitively. When an attribute value matches a TERM case-insensitively, the URI >>> is the one associated with that TERM. Note that the URI remains >>> case sensitive - no transformation is done on the input nor the >>> outpuy beyond our normal mapping of TERM to URI. >>> * Have RDFa Core permit host languages to define a default >>> collection of TERMs and their mappings. Define such a collection >>> in XHTML+RDFa and HTML+RDFa, and ensure the collection is identical. >>> * Require that if a host language defines a default collection, an >>> associated RDFa Profile document must contain the definitions of >>> the collection, must be at a well known URI, and must not change >>> without changing the URI. >>> * Permit conforming processors to hard code the declarations from >>> the host language-defined profile. >>> * Allow, but do not require, that authors indicate the profile in >>> use via @profile. >>> * Require that attribute values are compared to the current list of >>> TERMs before any processing associated with a value of @vocab. >>> >>> >>> The upshot of this is that rel='FoO' would match a pre-defined TERM of 'foo', which is what we want. And the URI associated with the TERM 'foo' would be used as the predicate for the resulting triple. There are no required server round-trips to determine the list of TERMs, but such round trips are permitted if you don't want to hard code the values into your processor (you would, however, have to hard code the profile URI). We should probably also commit to never reduce the collection of terms - only expand it. >>> >>> On a related note, we can also permit host languages to define anything else that can be present in an RDFa Profile. This would include, for example, prefix mappings. This is not technically required for what we are doing though - and I think as a group we already sort of agreed that it would be too difficult to define a collection of popular prefix mappings. >>> >>> The final related issue that I know of is the 'default prefix' mapping. This is the mapping that is used when a CURIE is encountered of the form ':foo'. RDFa Syntax and RDFa Core 1.1 both hard code this mapping to the XHTML vocabulary (http://www.w3.org/1999/xhtml/vocab#). We provide no mechanism for overriding this definition. I propose that we leave this alone. The use of ':foo' or ':someTermInXHTMLSpace' might be useful in the future. As an alternative, we could deprecate this use altogether - indicating that in a future version of RDFa that form of CURIE may be unresolvable. That doesn't seem necessary nor friendly to me. >>> >>> On 7/15/2010 11:08 AM, Shane McCarron wrote: >>> >>>> We had a good discussion on this issue today - I am sure the minutes will be out shortly. Unfortunately, this issue dovetails with many other related issues, so it is not completely straightforward to resolve. Worse yet, I now feel my proposal below was too simplistic - we need to view this in the context of a collection of issues: >>>> >>>> * case sensitivity of values in rel/rev >>>> * Terms enumerated in XHTML+RDFa >>>> * Terms defined in w3.org/1999/xhtml/vocab >>>> * LinkType values and their registration (IETF, WhatWG, HTML5) >>>> * Default vocabulary for Core, XHTML+RDFa, HTML+RDFa >>>> * Default profile for XHTML+RDFa and HTML+RDFa >>>> * Caching of profiles >>>> * Hardcoding of profiles and their evolution >>>> >>>> Consequently, I have withdrawn the proposal below. I am going to spend some time trying to address all of the above in a single proposal so we can hopefully resolve them all at once. Obviously, this will be more difficult. But resolving these issues piecemeal is bound to lead to confusion and an incomplete solution. >>>> >>>> Thanks in advance for your patience. >>>> >>>> On 7/13/2010 5:01 PM, Shane McCarron wrote: >>>> >>>>> In general, I feel that terms should always be treated as case sensitive. However, I agree that for backward compatibility reasons, the terms defined in *OUR* XHTML vocabulary, as extended by terms that are defined in HTML5, should be mapped to lower case when processing. >>>>> >>>>> I do not think this is an RDFa Core issue. Rather, I think that in RDFa Core we should say: >>>>> >>>>> TERMs, CURIEs, and URIs are all case sensitive. Host Languages may >>>>> place further processing requirements on TERMs (e.g., requiring they >>>>> be mapped to lower case). >>>>> >>>>> >>>>> In XHTML+RDFa 1.1 we should say: >>>>> >>>>> When referencing TERMs in the vocabulary at >>>>> http://www.w3.org/1999/xhtml/vocab, TERMs must be mapped to lower case. >>>>> >>>>> >>>>> I imagine we would need to say something similar in HTML+RDFa. >>>>> >>>>> >>>> >>> -- >>> Shane P. McCarron Phone: +1 763 786-8160 x120 >>> Managing Director Fax: +1 763 786-8180 >>> ApTest Minnesota Inet: shane@aptest.com >>> >>> >>> >>> >> >> ---- >> 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 >> >> >> >> >> >> > > -- > Shane P. McCarron Phone: +1 763 786-8160 x120 > Managing Director Fax: +1 763 786-8180 > ApTest Minnesota Inet: shane@aptest.com > > ---- 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, 22 July 2010 08:43:47 UTC