Problem/Motivation

Drupal 7 core outputs RDFa 1.0 by default, the version of RDFa which was recommended at the time of Drupal 7 release in January 2011. Since then, RDFa 1.1 was released and while the RDFa Working Group tried to keep RDFa 1.1 backward compatible with 1.0, there are a few features which were introduced to make RDFa 1.1 easier to author in the long run, which are not backward compatible with 1.0 out of the box. Note that this doesn't affect Drupal 7 sites which are using the default RDFa 1.0 doctype (which I believe is currently still the majority of Drupal 7 sites), but as people upgrade their doctype to RDFa 1.1/HTML5, this issue will start to appear more often, as reported by jneubert. The RDFa markup we generate for taxonomy terms is affected by one of the new features of RDFa 1.1, namely the @property attribute now takes the @href as property value by default, while in RDFa 1.0 @property was taking the value of the a element (the taxonomy term name). The a element wrapping usernames is also affected in the same way.

Proposed resolution

Using an empty @datatype attribute makes @property take on the value of the HTML element as opposed to the @href. This works in both RDFa 1.0 and RDFa 1.1: it is implicit in RDFa 1.0, but can be made explicit in RDFa 1.1 by adding the empty datatype attribute, indicating that the property value has to be a plain literal. This empty @datatype does not have any effect in RDFa 1.0 and does not change the RDF output, it is therefore safe to use it on sites which are still using the legacy RDFa 1.0 doctype. No new HTML element or no repeat content is required, simply an additional empty attribute. This is the new the markup for a taxonomy term:

<li class="taxonomy-term-reference-0" rel="dc:subject">
  <a property="rdfs:label skos:prefLabel" datatype="" typeof="skos:Concept" href="/plain/?q=taxonomy/term/1">xy</a>
</li>

I've published a couple of test HTML documents in RDFa 1.0 and RDFa 1.1 and you can view the generated RDF output in the RDF.rb Distiller (RDFa 1.0 example and RDFa 1.1 example) and in the W3C PyRDFa Distiller (RDFa 1.0 example and RDFa 1.1 example). In all 4 cases, the RDF output is the same.

Remaining tasks

A patch is available for review in #10.

Original report by jneubert

On an article page, the link to a taxonomy term is rendered as

<li class="taxonomy-term-reference-0" rel="dc:subject">
<a property="rdfs:label skos:prefLabel" typeof="skos:Concept" href="/plain/?q=taxonomy/term/1">xy</a>
</li>

RDFa Distiller extracts from this code snippet:

@prefix dc: <http://purl.org/dc/terms/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .

<> dc:subject [ rdfs:label </plain/?q=taxonomy/term/1>;
            skos:prefLabel </plain/?q=taxonomy/term/1> ] .

</plain/?q=taxonomy/term/1> a skos:Concept .

which is nosense. Instead of literals, the labels become object properties, the literal values are lost.

In my eyes, the entry should be rendered as something like

<li class="taxonomy-term-reference-0" rel="dc:subject">
<a typeof="skos:Concept" href="/plain/?q=taxonomy/term/1"><span property="rdfs:label skos:prefLabel">xy</span></a>
</li>

which would produce the intended

<> dc:subject </plain/?q=taxonomy/term/1> .

</plain/?q=taxonomy/term/1> a skos:Concept;
    rdfs:label "xy";
    skos:prefLabel "xy" .

I wondered if I did something wrong, but I could reproduce the issue in a plain Drupal 7.17 installation, as well as in plain Drupal 7.15. I'm quite sure that I have seen this differently (and correct) in a prior version.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jneubert’s picture

Hmm - the article's author entry look similarily weired:

<span rel="sioc:has_creator" datatype="xsd:dateTime" content="2012-11-23T09:33:31+01:00" property="dc:date dc:created">
Submitted by
<a class="username" property="foaf:name" typeof="sioc:UserAccount" about="/plain/?q=user/1" xml:lang="" title="View user profile." href="/plain/?q=user/1">admin</a>
on Fri, 11/23/2012 - 09:33
</span>

which produces the turtle code (prefixes omitted):

<> dc:created "2012-11-23T09:33:31+01:00"^^xsd:dateTime;
    dc:date "2012-11-23T09:33:31+01:00"^^xsd:dateTime;
    sioc:has_creator </plain/?q=user/1> .

</plain/?q=user/1> a sioc:UserAccount;
    foaf:name </plain/?q=user/1> .
scor’s picture

Could you indicate which doctype and which html element you're serving your page with? which theme are you using?

jneubert’s picture

I first observed this with a Zen 7.x-5.x subtheme with a <!DOCTYPE html> (HTML5), but I could reproduce it with an absolutly unmodified fresh Drupal installation with the standard Bartik theme. The examples are taken from the latter.

I'm not sure for which HTML element you are asking. Could you be more specific on this?

Thanks for looking into this - Joachim

Anonymous’s picture

Literals are extracted as expected when using Gregg Kellogg's RDF Distiller. It also works as expected with the Ubiquity Check RDFa tool.

If I had to make a wild guess, I'd say it's probably because of a backwards compatibility issue between RDFa 1.1 and 1.0. The tools that you tested it with are probably using RDFa 1.1's parsing rules.

scor’s picture

Project: Drupal core » RDFa
Version: 7.17 » 7.x-1.x-dev
Component: rdf.module » Code

Zen theme output HTML5 with not RDFa version so parsers will use the RDFa 1.1 parsing rules. If you paste a snippet, it will also be assumed to be RDFa 1.1. The processing of the a element has changed in 1.1, that's what you're experiencing here. I'll post a patch shortly.

Since core does not support RDFa 1.1, I'm moving this to the RDFa contrib module which deals with RDFa 1.1.

Anonymous’s picture

Just so it is noted here, my wild guess was wrong. Both the W3C's RDFa Distiller and Gregg Kellogg's RDF Distiller use the 1.1 parsing algorithm by default, so that doesn't explain the different results.

scor’s picture

Status: Active » Needs review
FileSize
1.81 KB

This patch implements the markup you suggested in the OP, which is to move the property attribute of the term title inside a new span element. Could you test and report back if it works for you?

PS: ignore tests results for now, the testbot doesn't seem to be able to checkout the code properly.

Status: Needs review » Needs work

The last submitted patch, 1848464_6_rdfa11.patch, failed testing.

jneubert’s picture

I applied the patch, and now it works for me - thank you very much for providing the patch.

scor’s picture

Title: Wrong RDFa markup produced for taxonomy terms » Make RDFa markup upward compatible with RDFa 1.1
Project: RDFa » Drupal core
Version: 7.x-1.x-dev » 8.x-dev
Component: Code » rdf.module
Assigned: Unassigned » scor
Status: Needs work » Needs review
Issue tags: +Needs backport to D7
FileSize
7.56 KB
8.24 KB

moving this issue back in the core queue, as I believe it can easily be fixed in Drupal 7 core by adding an empty datatype attribute in the RDFa markup (I've update the OP where you can find more details). Following core development policy, we need to get it fixed it in D8 first, so I'm uploading a patch for Drupal 8. I'm also uploading a patch for Drupal 7, it would be great if @jneubert could test this D7 patch to see if it works on his site. This patch can also be used as backport for Drupal 7 (once the d8 patch once been reviewed + committed).

These patches include updated tests using xpath, note however there is another set of issues to improve the accuracy of the RDF tests using an RDFa parser which I will update with this new RDFa markup as well: #1866858: Test RDFa by parsing RDFa (add the easyrdf library) and #1867096: Rewrite RdfaMarkupTest to parse RDFa.

scor’s picture

Issue summary: View changes

update OP to include proposal

Status: Needs review » Needs work
Issue tags: -Needs backport to D7

The last submitted patch, 1848464-rdfa11-10.patch, failed testing.

scor’s picture

Status: Needs work » Needs review

#10: 1848464-rdfa11-10.patch queued for re-testing.

Status: Needs review » Needs work
Issue tags: +Needs backport to D7

The last submitted patch, 1848464-rdfa11-10.patch, failed testing.

jneubert’s picture

Thank you for the great issue summary, the clever solution and the patch. It works fine for concepts: After reverting 1848464_6_rdfa11.patch and applying 1848464-rdfa11-10-d7-do-not-test.patch in my Drupal 7.17 dev environment, a tag on an article page is rendered like this:

<span class="field-item even" rel="schema:about dc:subject">
<a datatype="" property="rdfs:label skos:prefLabel" typeof="skos:Concept" href="/labs/en/taxonomy/term/3">Publishing Technologies</a>
</span>

which is distilled to

@prefix dc: <http://purl.org/dc/terms/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix schema: <http://schema.org/> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .

<> dc:subject </labs/en/taxonomy/term/3>;
    schema:about </labs/en/taxonomy/term/3> .

</labs/en/taxonomy/term/3> a skos:Concept;
    rdfs:label "Publishing Technologies";
    skos:prefLabel "Publishing Technologies" .

However (also in a plain drupal 7.17 installation, w/o rdfa, patch applied, concepts working) for the user name I still get:

<span rel="sioc:has_creator" datatype="xsd:dateTime" content="2012-10-06T13:09:55+02:00" property="dc:date dc:created">
Submitted by
<a class="username" property="foaf:name" typeof="sioc:UserAccount" about="/wt/?q=user/1" xml:lang="" title="View user profile." href="/wt/?q=user/1">admin</a>
on Sat, 10/06/2012 - 13:09
</span>

which is destilled to

@prefix dc: <http://purl.org/dc/terms/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix sioc: <http://rdfs.org/sioc/ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<> dc:created "2012-10-06T13:09:55+02:00"^^xsd:dateTime;
    dc:date "2012-10-06T13:09:55+02:00"^^xsd:dateTime;
    sioc:has_creator </wt/?q=user/1> .

</wt/?q=user/1> a sioc:UserAccount;
    foaf:name </wt/?q=user/1> .
scor’s picture

Status: Needs work » Needs review
FileSize
7.54 KB
8.23 KB

I found a silly copy paste issue in the code, fixed now in D8 and D7 patch. It wasn't causing any issue in the D8 patch, but was in the D7 backport due to a difference in the $variable theme function. @jneubert, could you try again this new D7 patch?

jneubert’s picture

Works perfectly now for concept and user!

Thanks again - Joachim

Anonymous’s picture

Status: Needs review » Reviewed & tested by the community

Since this is required for #1867096: Rewrite RdfaMarkupTest to parse RDFa and is mostly replaced by that patch, I'm RTBC-ing.

webchick’s picture

Version: 8.x-dev » 7.x-dev
Status: Reviewed & tested by the community » Patch (to be ported)

Lovely! Nice to see some action in the RDF queue! :)

Committed and pushed to 8.x. Thanks!

Moving to backport from D7, although I'm sure David will have some more questions about the implications for existing sites out there.

scor’s picture

Status: Patch (to be ported) » Needs review
FileSize
7.54 KB

Attached is a backport for Drupal 7. exact same approach as in Drupal 8.

David_Rothstein’s picture

So if I'm understanding this right it's just a new empty attribute in the HTML that seems unlikely to break anything for anyone? If so, that sounds fine to me... but maybe I should be asking more questions :)

We'd need to mention this in the release notes, of course.

scor’s picture

FileSize
531 bytes
8.06 KB

good point: added this change to CHANGELOG.txt

jneubert’s picture

Status: Needs review » Reviewed & tested by the community

I re-applied the latest patch (#21) to my RDFa 1.1 development environment and also to a plain Drupal (RDFa 1.0) environment. It works on both, and the output validates against RDFa Distiller for RDFa 1.1/1.0 respectivly. Therefore, I mark it RTBC.

David_Rothstein’s picture

Status: Reviewed & tested by the community » Fixed
Issue tags: +7.22 release notes

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

add link to comment