Re: Summary of current state of ISSUE-135

Thanks for the summary and survey Stéphane!

And I agree with Ivan, especially with the specifics of ISSUE-135 in mind.

Of course, as you said, there were lots of nuances that where weighed
in the decision, and I'd like to elaborate on those for completeness.
Fear not, I have no intention of challenging any of our resolutions. I
just want to make it (painfully) clear how many aspects have been
considered in this.

Primarily, our chosen resolution prevents unexpected differences in
results depending on actual term used in @rel. If instead the
resolution had been to only allow predefined terms in @rel, the effect
of using e.g. "license" (instead of say "nofollow") in a @rel would
have radically changed the resulting triples if a @property was also
used (part of the core of ISSUE-135). It would also have resulted in a
radical departure from RDFa 1.1 Core, where @rel and @property share
the same value space.

There was also a *related* concern, which may have been conflated with
this issue during our discussions. This was about the fact that using
@rel alone within a @vocab scope may cause junk triples. That is fully
preventable by an aware author, but isn't apparent to someone only
knowing Lite and using e.g. "nofollow" or "tooltip" within such scope.
It was aggravated in the case of ISSUE-135, and our solution fixed
that with nearly no other consequence.

But therefore, by design, we also also keep the effect of @vocab on
@rel terms intact (consistent with RDFa 1.1 Core). Both the effect of
expanding "junk" like "stylesheet", "nofollow", "prefetch", "me" and
"sweetheart" (for which there are no well-defined IRIs). And also that
predefined terms like "license" is affected by @vocab.

Of course, being me, I have continued to ponder quite a lot about this
at large (including considering a "blacklist" of terms to be dropped
regardless of the presence of @property). But use of rel terms is wide
and varied: consider the IANA relations [1], the somewhat conflicting
list of XHTML vocabulary terms [2] (mostly dropped in RDFa 1.1 Core),
the semantically dubious nature of HTML5 annotations [3], the growing
list of microformat terms [4], etc. That really shows us one thing:
there is no clear consensus on @rel terms. We've thus left it fully up
to the author to control them with @vocab. There is a risk of junk,
but it's preventable. Either by setting @vocab to nothing, or (perhaps
better) by adding an empty @property to achieve the "muting" effect
our resolution defines.

If we had considered @rel as a semantic attribute a lost cause, it
could have been deprecated, or it become a semi-managed value space.
We have chosen not to treat it like that in HTML5 either. Use of
non-semantic rel terms like "nofollow" and "tooltip" should therefore
happen outside of regions where @vocab is in effect, or should be
selectively muted. Similarly, @vocab should not be unintentionally
used in <head>. (Of course, inversely, authors who want to convey
meaning from any of these terms similarly has the means to do so.)

My point is only to explicitly state this design decision. If anyone
finds this intolerable, there is still a slim chance to do something
more to manage @rel terms in HTML5. We haven't had this specific issue
raised though, although we've touched upon this consequence both for
ISSUE-129 and ISSUE-135.

So I do agree with Ivan that ISSUE-135 is satisfactorily resolved. I
am also explicitly fine with moving on from all of this. But I wanted
to fully express *why* I think so.

Best regards,
Niklas

(Aside: In part, the situation in @rel is also a consequence of the
resolution of ISSUE-129 [5]: the power of @vocab. That in turn was
made to ensure that use of @vocab with @property is not scrambled by a
possibly growing list of hard-coded terms. If it had not been done,
the situation in @rel could, in theory, be managed by diligent
maintenance of the HTML5 RDFa Profile; by adding terms, perhaps some
with no bound IRIs, to keep the anarchy of @rel in check. The
reasonably intolerable downside of that would of course be that those
terms would be on a collision course with *any* future @vocab term
(schema.org comes to mind). A complex alternative would be a different
behaviour for @rel alone of course, but I doubt that it would be seen
as worthwhile.)

[1]: http://www.iana.org/assignments/link-relations/link-relations.xml
[2]: http://www.w3.org/2011/rdfa-context/xhtml-rdfa-1.1
[3]: http://www.w3.org/TR/html5-author/links.html#hyperlink-annotation
[4]: http://microformats.org/wiki/existing-rel-values
[5]: http://www.w3.org/2010/02/rdfa/track/issues/129


On Thu, Sep 6, 2012 at 8:50 AM, Ivan Herman <ivan@w3.org> wrote:
> Thanks Stéphane, it is good to get reminded for people like me, whose memory is failing:-)
>
> I would propose NOT to re-discuss this issue; we did it ad nauseam back then. I would propose to close this issue formally by adopting the resolution we took then, and move on.
>
> Ivan
>
>
> On Sep 6, 2012, at 08:26 , Stéphane Corlosquet wrote:
>
>> The aim of ISSUE-135 is to prevent a non-RDFa @rel to disable the new behavior of @property in RDFa+HTML5. In HTML5, @rel is used for many purposes ([1] and [2]), many of them are irrelevant to RDFa. When HTML authors use these values in @rel, they most likely don't do it with RDFa in mind, and in this context the behavior of @property should not change when a non-RDFa @rel is added to the same element.
>>
>> In other words, the following two paragraphs should generate the same triples:
>> <p vocab="http://schema.org/" typeof="Person">
>>    My name is <a href="http://example.com/" property="homepage">Stephane Corlosquet</a>.
>> </p>
>> <p vocab="http://schema.org/" typeof="Person">
>>    My name is <a href="http://example.com/" property="homepage" rel="me">Stephane Corlosquet</a>.
>> </p>
>>
>> This issue has been discussed on the mailing list [3] and then during the call on May 10th [4]. The following two options were discussed on the call:
>> 1) If you have an element that has both @rel and @property in HTML5, then the @rel can only take CURIEs, which will result in things like rel="nofollow" being ignored
>> 2) There is a more global one that in HTML5+RDFa a @rel value can only have CURIEs.
>>
>> The following resolution was taken (essentially option 1):
>> "If @property and @rel/@rev are on the same elements, the non-CURIE and non-URI @rel/@rev values are ignored. If, after this, the value of @rel/@rev becomes empty, then the then the processor must act as if the attribute is not present."
>>
>> This resolution ensures that rel="license" on an element with no @property is still supported.
>>
>> Here is a quick survey of some authoritative sites which are using or promoting rel="license". I found that very few are combining @property with @rel in the same element, and when they do, they always use cc:license in @rel. In other words, I could not find any example that would break with the option choosen above. Here are the sources I looked at:
>>
>> # No use of @property and @rel in the same element:
>> A random wikipedia page: http://en.wikipedia.org/wiki/The_Garden_of_Forking_Paths
>> A random Flickr page: http://www.flickr.com/photos/60223652@N00/2677272571/
>> http://microformats.org/wiki/rel-license
>> http://www.alistapart.com/articles/introduction-to-rdfa/
>> http://reference.sitepoint.com/html/rel-mf
>>
>> # Use of @property and @rel in the same element using CURIEs:
>> http://wiki.creativecommons.org/RDFa
>> http://labs.creativecommons.org/2011/ccrel-guide/
>> http://labs.creativecommons.org/2011/ccrel-guide/examples/multiple_textimage.html
>> http://wiki.creativecommons.org/License_Deeds_%28Metadata%29
>>
>> # Use of @property and rel="license":
>> *none*
>>
>> Steph.
>>
>> [1] http://www.w3.org/TR/html5-author/links.html#linkTypes
>> [2] http://microformats.org/wiki/existing-rel-values
>> [3] http://www.w3.org/2010/02/rdfa/track/issues/135
>> [4] http://www.w3.org/2010/02/rdfa/meetings/2012-05-10#ISSUE__2d_135__3a__RDFa_Lite_and_non__2d_RDFa___40_rel_values
>
>
> ----
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> FOAF: http://www.ivan-herman.net/foaf.rdf
>
>
>
>
>
>

Received on Thursday, 6 September 2012 13:55:56 UTC