Re: Usage of @rel in RDFa with @vocab: is it a bug? Should it be a bug?

Ah, the old "@rel is too crowded, there will be a brawl"...

The case that Robin gives was brought up back then [1] and was not
considered problematic (enough). (Basically, people are to either avoid
@vocab on the html and head elements (which is the common case with
schema.org), or to cancel out @rel values by combining them with (possibly
empty) @property attributes, or to use a value of "
http://www.w3.org/1999/xhtml/vocab#" to be able to capture the standard
semantics.)

A related case (that I think Stephane originally brought up) was addressed
though (at a later point): when @property and predefined/non-qualified @rel
values interfered. We fixed that by introducing rule 7 in section 3.1 [2].

If the rules can be updated, the now given problem can be addressed by
modifying rule 7 from:

7. In Section 7.5: Sequence, immediately after processing step 4, if the
@property attribute and the @rel and/or @rev attribute exists on the same
element, the non-CURIE and non-URI @rel and @rev values are ignored. If,
after this, the value of @rel and/or @rev becomes empty, then the processor
must act as if the respective attribute is not present.

to something like:

7. In Section 7.5: Sequence, immediately after processing step 4, if the
@property attribute and the @rel and/or @rev attribute exists on the same
element, OR the element is either a link or an a, the non-CURIE and non-URI
@rel and @rev values are ignored. If, after this, the value of @rel and/or
@rev becomes empty, then the processor must act as if the respective
attribute is not present.

To have the effect that Ivan suggests. (I.e. add "OR the element is either
a link or an a, " after the third comma in the rule.)

The resulting backwards incompatibility would affect anyone using *full*
RDFa 1.1 in HTML5 who is relying on @vocab and @rel/@rev on <a> or <link>
specifically. Does anyone (Shane?) know if this is used in the wild? If
this is so, those uses can either switch to @property on <a> or use
CURIEorIRI values in @rel/@rev (note that <link> isn't allowed as flow
content without @property being present).

Note that there has been talk about the merits of @rev (e.g. on
public-vocabs), to the extent that it has been proposed to also be added to
microdata (to mirror the equivalent @reverse feature used in JSON-LD). But
AFAIK that has mainly been in the context of "container" elements (to
capture nested content in reverse order). If that is correct, the intended
uses would be unaffected by this. I do recall one example though (by Dan,
IIRC) for using both @rel and @rev on an <a>. Dan, do you know more about
that?

Cheers,
Niklas

[1]: https://lists.w3.org/Archives/Public/public-rdfa-wg/2012Feb/0021.html
[2]: http://www.w3.org/TR/html-rdfa/#additional-rules


On Fri, Nov 20, 2015 at 5:33 AM, Ivan Herman <ivan@w3.org> wrote:

>
> > On 19 Nov 2015, at 19:58, Gregg Kellogg <gregg@greggkellogg.net> wrote:
> >
> > In discussions at the time, IIRC, @rel was intended to work with @vocab
> to be consistent. But Robin’s right that this makes a mess of HTML
> containment rules. Without vocab, terms are defined in the RDFa initial
> context (not RDFa+HTML5 specifically). These are in the  <
> http://www.w3.org/1999/xhtml/vocab#> namespace, (e.g., <
> http://www.w3.org/1999/xhtml/vocab#alternate>) so that “alternate”
> expands relative to that namespace, but it could be any URI defined in any
> initial context; I don’t think we defined a precedent order.
> >
> > On the one hand, this is clearly a bug related to HTML5, as values of
> @rel can take on different meanings. On the other hand, we break this by
> allowing TERMorCURIEorAbsIRI, so that a CURIE or absolute IRI is
> inconsistent with the HTML5 content model, but is certainly not ambiguous.
> >
> > If we can add an errata for RDFa in HTML to say that using this to
> interpret values of @rel is a bug (even though it’s specifically described
> in RDFa Core 1.1 section 5.1) it would probably make the most people happy.
> But, it will likely break some tests.
>
> Clearly, any change we make here is backward incompatible. Therein lies
> the biggest problem, actually.
>
> We can reduce the problem, as I said, is to restrict the changes to the
> legitimate HTML5 @rel usage in the absence of RDFa, ie, as part of <a> or
> <link>
>
> Ivan
>
>
> >
> > Gregg Kellogg
> > gregg@greggkellogg.net
> >
> >> On Nov 19, 2015, at 7:55 AM, Robin Berjon <robin@berjon.com> wrote:
> >>
> >> On 19/11/2015 10:45 , Shane McCarron wrote:
> >>> I don't feel this is a bug at all.  It is as designed.  In fact, the
> >>> whole thing with @vocab was to permit the dpub (daisy and others)
> >>> community to switch into their own vocabulary so they would not need to
> >>> prefix their terms.  I don't see how we could back away from that at
> >>> this late date.
> >>
> >> Most `rel` values have no expectation of being treated as prefix-less
> >> CURIEs. They are meant to be just that short string.
> >>
> >> As far as I can tell, the following actually produces a triple:
> >>
> >> <html resource="http://berjon.com/" vocab="http://foo.org/">
> >> <head>
> >>   <link rel="stylesheet" href="http://berjon.com/pretty.css"/>
> >> </head>
> >> </html>
> >>
> >> Testing that out, I get:
> >>
> >> <http://berjon.com/>
> >>  <http://foo.org/stylesheet> <http://berjon.com/pretty.css> .
> >>
> >> Which is absurd. What did I miss in the spec(s) that protects against
> >> this sort of thing?
> >>
> >> --
> >> • Robin Berjon - http://berjon.com/ - @robinberjon
> >> • http://science.ai/ — intelligent science publishing
> >> •
> >>
> >>
> >
>
>
> ----
> Ivan Herman, W3C
> Digital Publishing Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> ORCID ID: http://orcid.org/0000-0003-0782-2704
>
>
>
>
>