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

Alex,

just small remarks again, because I do not have my machine with me. Typing a mail on these other devices is no fun...

- There are already differences between core, XHTML1 and HTML5/XHTML5. The former has a number of inherited predefined rel values, the latter only two or three. We had long discussions on this in the group, and that is the compromise we have. Personally, I would have been in favour of having the minimal set for both, but the backward compatibility issue was compelling. Let us not try to harmonize on this. In fact, with HTML5 planned to be a standard in about a year, I think the future is for HTML5 (whether in XHTML5 format or not); that is what we should optimize for.

- Yes, introducing this change in HTML means that the host language modifies, conceptually, the generic algorithm (although, implementation wise, this can be done by a preprocessing step on the DOM tree). That is also the case already: HTML5 adds some additional elements and attributes, like date or data to the processing of RDFa. We could have come up with a complex and generic profile definiton, run time mechanism to describe the changes on the core steps, etc, but that would have made things more complicated. It was not worth it. All this means that adding Stéphane's option #1 is not fundamentally new.

- I can see the point that the changes introduce an assymetry in term processing between @property and @rel. And, maybe, it would be an acceptable extension of option #1 to have the same ignore mechanism for @property, too. I do not know whether we would then result in ignoring bona fide vocabulary terms from, say, schema,org; maybe somebody whose day is not yet over, could check... But if there are no danger, I am symphatetic to tha (though not yet fully sure)t. That being said, this may be quite a corner case, I am not sure it is very important in practice.

So... ain't pritty, I agree. Maybe the real flaw was to reuse the HTML @rel attribute for RDFa purposes; maybe we should have used our own attribute here. This error, if it is one, has been made years ago. We should now go with the best suboptimal solution, and I still believe option #1, which does have a hack feel indeed, is the best approach in providing a practical solution to practical problems and will, ultimately, contribute to the adoption of RDFa.

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 19:51:24 UTC