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

> On Nov 20, 2015, at 8:44 AM, Niklas Lindström <lindstream@gmail.com> wrote:
> 
> 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 <http://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# <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?

We added @itemprop-reverse as an experimental feature [3] to Microdata to RDF for this purpose.

The use case is illustrated in issue 5 [4]:

<div itemscope itemtype="http://schema.org/Organization">
   <span itemprop="name">Cryptography Users</span>
   <div itemprop-reverse="memberOf" itemprop="member" itemscope
         itemtype="http://schema.org/OrganizationRole">
     <div itemprop-reverse="memberOf" itemprop="member" itemscope
             itemtype="http://schema.org/Person">
       <span itemprop="name">Alice</span>
     </div>
     <span itemprop="startDate">1977</span>
   </div>
</div>

Basically, in the case where an organization contains users (through an OrganizationRole), the the users are members of the Organization. You could do the same thing in RDFa with @rev, and in JSON-LD, as you note.

The idea was that schema.org examples may start using this, and if there is sufficient evidence in the wild, it would be added to Microdata, and would become a standard feature of Microdata to RDF. Not sure what’s happened to it since, but these things come up again from time to time.

Gregg

> Cheers,
> Niklas
> 
> [1]: https://lists.w3.org/Archives/Public/public-rdfa-wg/2012Feb/0021.html <https://lists.w3.org/Archives/Public/public-rdfa-wg/2012Feb/0021.html>
> [2]: http://www.w3.org/TR/html-rdfa/#additional-rules <http://www.w3.org/TR/html-rdfa/#additional-rules>[3] http://www.w3.org/TR/microdata-rdf/#reverse-itemprop
[4] https://github.com/w3c/microdata-rdf/issues/5

> On Fri, Nov 20, 2015 at 5:33 AM, Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>> wrote:
> 
> > On 19 Nov 2015, at 19:58, Gregg Kellogg <gregg@greggkellogg.net <mailto: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# <http://www.w3.org/1999/xhtml/vocab#>> namespace, (e.g., <http://www.w3.org/1999/xhtml/vocab#alternate <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 <mailto:gregg@greggkellogg.net>
> >
> >> On Nov 19, 2015, at 7:55 AM, Robin Berjon <robin@berjon.com <mailto: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/ <http://berjon.com/>" vocab="http://foo.org/ <http://foo.org/>">
> >> <head>
> >>   <link rel="stylesheet" href="http://berjon.com/pretty.css <http://berjon.com/pretty.css>"/>
> >> </head>
> >> </html>
> >>
> >> Testing that out, I get:
> >>
> >> <http://berjon.com/ <http://berjon.com/>>
> >>  <http://foo.org/stylesheet <http://foo.org/stylesheet>> <http://berjon.com/pretty.css <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/ <http://berjon.com/> - @robinberjon
> >> • http://science.ai/ <http://science.ai/> — intelligent science publishing
> >> •
> >>
> >>
> >
> 
> 
> ----
> Ivan Herman, W3C
> Digital Publishing Lead
> Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
> mobile: +31-641044153 <tel:%2B31-641044153>
> ORCID ID: http://orcid.org/0000-0003-0782-2704 <http://orcid.org/0000-0003-0782-2704>
> 
> 
> 
> 
>