Re: RDFa Lite and non-RDFa @rel values [Final Take?]

On Apr 25, 2012, at 1:32 PM, Dan Brickley wrote:

> On 25 April 2012 21:50, Ivan Herman <ivan@w3.org> wrote:
>> [snip]
> 
> Could someone clarify what the story looks like if all RDF-ish stuff
> goes into @property, along lines of RDFa Lite? is the risk just that
> of some 'junk' or poorly patterned triples driven from rel='me',
> rel='nofollow' etc?

Yes, the risk is basically that if someone sticks to RDFa 1.1 Lite, and only uses the basic properties (@property, @voabulary, @resource, @typeof and @prefix), that the generated RDF could be different if an @rel value was inserted, perhaps after the fact. The example that's been sited is one with an anchor having @rel="nofollow":

<p vocab="http://schema.org/" typeof="Person">
  My name is <a href="http://example.com/" property="homepage">Stéphane Corlosquet</a>.
</p>

The code could have ben generated without the rel="nofollow" and generate the RDF as expected:

<a> a schema:Person;
  schema:homepage <http://example.com/> .

If some well-meaning person then cam along and added @rel=nofollow, it would generate entirely different results:

<a> a schema:Person;
  xhv:nofollow <http://example.com/>;
  schema:homepage "Stéphane Corlosquet" .

The idea is to remove @rel from consideration for RDF generation if it is comprised solely of HTML link relation terms that are not also RDFa terms.

The thing is that @rel remains a valid RDFa 1.1 property (not RDFa 1.1 Lite conformant, but a conforming processor MUST process @rel). Adding a rule, specifically for HTML+RDFa 1.1 (which includes both HTML5 and XHTML5), that removes these "junk" link relations from consideration solves the problem for the typical junk link relation terms.

Gregg

> Dan
> 
>> Sorry if we disagree here, Alex...
>> 
>> Cheers
>> 
>> Ivan
>> 
>> ---
>> Ivan Herman
>> Tel:+31 641044153
>> http://www.ivan-herman.net
>> 
>> (Written on mobile, sorry for brevity and misspellings...)
>> 
>> 
>> 
>> On 25 Apr 2012, at 20:24, Alex Milowski <alex@milowski.com> wrote:
>> 
>>> On Wed, Apr 25, 2012 at 9:28 AM, Gregg Kellogg <gregg@greggkellogg.net> wrote:
>>>>> 
>>>>> Bottom line: I am still in favour of Stéphane's option 1. The only other alternative I can live with is to stay with the status quo and move on.
>>>> 
>>>> I think Stéphane's option 1 is the way to go. Not doing this will result in much more bad behavior than leaving the status quo, IMO.
>>>> 
>>> 
>>> Here is, hopefully, my final take on all of this.  Thanks for bearing with me.
>>> 
>>> 
>>> I went back through all of this and option 1 is stated as:
>>> 
>>>   Option #1: ignore @rel if it only includes HTML Link types as
>>> defined at http://www.w3.org/TR/html5-author/links.html#linkTypes
>>> 
>>> and the original problem was:
>>> 
>>> <p vocab="http://schema.org/" typeof="Person">
>>>   My name is <a href="http://example.com/" property="homepage"
>>> rel="nofollow">Stéphane Corlosquet</a>.
>>> </p>
>>> 
>>> generates, for text/html:
>>> 
>>> <> a schema:Person;
>>>   schema:homepage "Stephane Corlosquet";
>>>   schema:nofollow <http://example.com/>.
>>> 
>>> and generates for application/xhtml+xml:
>>> 
>>> <> a schema:Person;
>>>   schema:homepage "Stephane Corlosquet";
>>>   <http://www.w3.org/1999/xhtml#nofollow> <http://example.com/>.
>>> 
>>> There are really three problems that have been identified:
>>> 
>>>   1. The different interpretation of @property given the presence of @rel.
>>> 
>>>   2. Do values like "nofollow" and "alternate" generate triples in
>>> HTML or XHTML documents?
>>> 
>>>   2. Different triples are generated depending on whether the
>>> fragment is in an HTML or XHTML serialized document.
>>> 
>>> It is quite possible for the same document markup to be serialized via
>>> HTML5 as either HTML syntax or XHTML syntax.  The referring
>>> specification is still HTML5.  I think it would be really, really
>>> unfortunate to continue generating different triples.  Personally, I
>>> wish I had noticed that earlier but I didn't.
>>> 
>>> We need to parse out what option #1 really means in terms of the three
>>> specifications HTML+RDFa 1.1, XHTML+RDFa 1.1, and RDFa Core 1.1 and
>>> these three problems.
>>> 
>>> For problem 1:
>>> 
>>> Adjusting the interpretation of @rel values for HTML doesn't fix the
>>> problem in general.  @property will be interpreted differently if you
>>> use a CURIE.   The status quo is a "you lose, it is a quirk" situation
>>> and having special cases for HTML/XHTML feels very unsatisfactory.
>>> Especially given that we have no dynamic mechanism for loading a
>>> profile for a host language.  That is, we're building in special case
>>> process for specific media types that only "fixes" this form them
>>> alone.
>>> 
>>> In retrospect, it was probably a mistake to use the presence of the
>>> @rel/@rev attributes rather than their resolved values regardless of
>>> the kind of document being processed.
>>> 
>>> Fixing this for HTML/XHTML without changing RDFa Core 1.1 requires
>>> change HTML+RDFa 1.1. and/or XHTML+RDFa 1.1 to modify the definition
>>> of "present" used in step 11 of section "7.5 Sequence" in the RDFa
>>> Core 1.1 document.  It would only be available with these two media
>>> types.  Note that we have the same problem if someone puts an empty
>>> @rel attribute.
>>> 
>>> It would be much better to have the language adjusted in RDFa Core 1.1
>>> to address the resolved value.  That's probably a substantive change
>>> to that specification.
>>> 
>>> 
>>> For problem 2:
>>> 
>>> I just had a long talk with Murray Maloney about the history of
>>> @rel/@rev in HTML.  One gem that came from that conversation was that
>>> it would have been much better to have used a CURIE or a URI.  I can
>>> see that viewpoint and what we have today can be considered a
>>> syntactic convenience.  Does that mean that they shouldn't generate a
>>> triple?  @rel="license" is just as important as @rel="dc:rights"
>>> 
>>> I've said myself, that the set of actual values isn't well defined
>>> beyond what is listed in the HTML5 (or previous) specification.  XHTML
>>> 1.1 had a different set but, looking forward, the only consistent set
>>> is what is in HTML5.
>>> 
>>> If a @rel value can be ignored, there is a new feature being
>>> introduced for terms.  Essentially, there is a set of term tokens that
>>> can be ignored.  All places where terms are processed should have the
>>> same interpretation.
>>> 
>>> If we go as far as excluding @rel="alternate", etc. in XHTML as well,
>>> we'd have a problem in that other attributes like @property would have
>>> inconsistent term processing unless we excluded them there as well.
>>> 
>>> So, terms that are ignored need to be ignored everywhere.
>>> 
>>> 
>>> For problem 3:
>>> 
>>> Even though I have stated a preference for allowing and using HTML5's
>>> rel values, I want even more a consistent world view between HTML and
>>> XHTML syntaxes.  We should get the same triples for the same markup.
>>> Choices about the terms being ignored in HTML syntax documents should
>>> be the same for XHTML syntax documents.
>>> 
>>> We want these worlds to converge as much as possible.  This does mean
>>> we might be breaking with the past in terms of RDFa and XHTML 1.1.
>>> Since we have HTML5, I assert that all we will have is XHTML as HTML5
>>> defines it.
>>> 
>>> All this means we would need to change both HTML+RDFa 1.1 and
>>> XHTML+RDFa 1.1 in some way (or combine them) so that their initial
>>> contexts and other processing rules are virtually the same.
>>> 
>>> --
>>> --Alex Milowski
>>> "The excellence of grammar as a guide is proportional to the paucity of the
>>> inflexions, i.e. to the degree of analysis effected by the language
>>> considered."
>>> 
>>> Bertrand Russell in a footnote of Principles of Mathematics
>>> 
>> 
>

Received on Wednesday, 25 April 2012 20:52:40 UTC