I just realized that the HTML output generated by certain field formatters interferes with the RDFa parsing, producing some inconsistent RDF. To explain, let's look at 2 examples.
Example 1: image field
Create an article with an image attached to it.
Full node:
<div class="field field-name-field-image field-type-image field-label-hidden clearfix">
<div class="field-items">
<div rel="rdfs:seeAlso" class="field-item even">
<img src="http://localhost/image/generate/large/public/field/image/2009iswc.png"/>
</div>
</div>
</div>
Equivalent RDF: <> rdfs:seeAlso <http://localhost/image/generate/large/public/field/image/2009iswc.png>
Teaser:
<div class="field field-name-field-image field-type-image field-label-hidden clearfix">
<div class="field-items">
<div rel="rdfs:seeAlso" class="field-item even">
<a href="/node/1"><img src="http://localhost/image/generate/medium/public/field/image/2009iswc.png"/></a>
</div>
</div>
</div>
Equivalent RDF: <> rdfs:seeAlso <http://localhost/node/1>
The RDF produced by the teaser is not the same as the RDF produced by the full node of the same article. The full node RDFa is good, while the teaser links to itself which is not what we expect. This glitch is due to the @href of the a tag wrapping the img tag (RDFa parsers take the first @href/@src available in the tag containing the @rel, or in the first children tag containing @href/@src).
Example 2: file field
Add a file field to a content type and create node with a txt file attached to it.
<div class="field field-name-field-file field-type-file field-label-above clearfix">
<div class="field-label">file: </div>
<div class="field-items">
<div rel="rdfs:seeAlso" class="field-item even">
<span class="file">
<img src="/modules/file/icons/text-plain.png" title="text/plain"/>
<a href="http://localhost/sites/default/files/swcambridge-20091208.txt">swcambridge-20091208.txt</a>
</span>
</div>
</div>
</div>
Equivalent RDF:
<> rdfs:seeAlso <http://localhost/modules/file/icons/text-plain.png>
<> rdfs:seeAlso <http://localhost/sites/default/files/swcambridge-20091208.txt>
Here, the problem is that the icon for the attachment text-plain.txt is picked up by the RDFa chaining: because the last div tag does not contain any @href, @src or @resource, the objects of the mapping rdfs:seeAlso are all the children tags containing either @href/@src.
Conclusion
This only affects the fields containing a link to another resource (aka of type owl:ObjectProperty) like image and file, but does not affect text or numeric type fields.
One way to solve this is by adding a @resource attribute with the url of the file/image in the same div as the rel attribute:
<div class="field field-name-field-file field-type-file field-label-above clearfix">
<div class="field-label">file: </div>
<div class="field-items">
<div rel="rdfs:seeAlso" resource="http://localhost/sites/default/files/swcambridge-20091208.txt" class="field-item even">
<span class="file">
<img src="/modules/file/icons/text-plain.png" title="text/plain"/>
<a href="http://localhost/sites/default/files/swcambridge-20091208.txt">swcambridge-20091208.txt</a>
</span>
</div>
</div>
</div>
| Comment | File | Size | Author |
|---|---|---|---|
| #33 | drupal-rdf-678594-33.patch | 557 bytes | oriol_e9g |
| #29 | terminal.png | 13.91 KB | xjm |
| #29 | dreditor.png | 13.79 KB | xjm |
| #25 | drupal-rdf-707484-rdfa-image-markup-documentation-25.patch | 578 bytes | kathyh |
| #23 | drupal-rdf-707484-rdfa-image-markup-documentation-23.patch | 558 bytes | mlncn |
Comments
Comment #1
Anonymous (not verified) commentedThis patch checks to see whether the field has a File ID. If it does, it sets the resource attribute to the file url.
Let me know if there are any problems with this approach, I will start working on the test for this issue.
Comment #2
scor commented- we should isset() or !empty() here to avoid notices when $item['fid'] is not defined.
- how about testing for $item['uri'] directly in the if condition instead of $item['fid']?
This is the approach that first came to my mind too, and it works well for file/image fields, not sure yet whether we should do something more generic, or let the contrib module implementing new field formatter to deal with this situation like we do here. For instance, a more generic approach would be to let fields specify the resource there describing by adding a resource key in each item array, and rdf.module would use that value if it exists. However this would be an API change which a bit late at this stage, and we should probably go with the approach of #1.
Powered by Dreditor.
Comment #3
Anonymous (not verified) commentedYeah, I realized the isset issue when I started writing the test for it.
The patch has the fix for that as well as a test which uploads both an image and a text file.
If this goes in as an API change, it would allow for the use of hash URIs as well, which would be a bonus.
Comment #4
scor commentedsending patch for testing.
Comment #6
Anonymous (not verified) commentedI changed the conditional to test for $item['uri']. This may also catch link fields if link module changed its array key from 'url' to 'uri', but that shouldn't cause problems.
This patch will not currently pass tests. The test for the rel property on field_image is dependent on the change to the rdf mapping in the standard install profile, as detailed in this issue #632484: Update the default profile with the proper RDF mapping.
Once that patch is committed, this should be good to go.
Comment #7
scor commentedsetting for review.
Comment #8
Anonymous (not verified) commentedEDIT: WRONG PATCH
Comment #9
Anonymous (not verified) commentedHere is a patch that sets the @resource to the resized image if there is an image style set for the field.
Comment #10
scor commentedLet's merge #642596: Annotate images with RDFa 'typeof' with this issue given they're touching the same code now.
Comment #11
Anonymous (not verified) commentedGood idea, the two are now merged.
Comment #12
aspilicious commentedrun bot
Comment #13
scor commentedWe should add foaf:Image as an array instead of a string so it's more compatible with other modules willing to add other values to the attribute.
some whitespaces to remove at end of lines (there are more than above).
This review is powered by Dreditor.
Comment #14
Anonymous (not verified) commentedThis should fix all the whitespace and uses an array for foaf:Image
Comment #15
Anonymous (not verified) commentedComment #17
scor commenteddebugging cruft code
this change is not necessary
Comment #18
Anonymous (not verified) commentedWhoops on the debug message. Here is the new patch.
Comment #19
scor commentedThis is ready. thanks Lin.
Comment #20
dries commentedCommitted to CVS HEAD. Thanks.
Comment #22
scor commentedI think we ought to add a line of explanation here to explain why we're not using the usual entity type to store this foaf:Image type. Image does not have its own entity type or bundle, and therefore we cannot store it like the rest of the mappings. The closest entity is file which has a file bundle. I wonder if an image bundle would have made sense, but that's too late for core.
Comment #23
mlncn commentedHere is a comment-only patch to address this. Drupal 8 first but should apply to Drupal 7.
Comment #24
xjmTagging as novice for the task of rerolling the Drupal 8.x patch on account of #22336: Move all core Drupal files under a /core folder to improve usability and upgrades.
If you need help rerolling this patch, you can come to core office hours or ask in #drupal-gitsupport on IRC.
Comment #25
kathyh commentedUpdated for #24 - D8 /core
Comment #26
xjmMore properly a docs issue? Or no since it's an inline comment? Looks good to me in either case.
Comment #27
catchDocs change looks fine but dreditor says mapping is bleeding over 80 chars.
Comment #28
xjm@catch: Update dreditor. :) Old versions counted the patch margin in the char limit.
Comment #29
xjmComment #30
catchHmm my dreditor disagrees but those screenshots don't lie.
Committed/pushed to 8.x. This wasn't tagged for backport but looks like it should be.
Comment #31
dave reid@scor: Maybe you could help us look at http://drupal.org/project/file_entity and see if we need additional RDF there as we do support file 'bundles' there (e.g. 'image', 'audio', 'video').
Comment #32
xjmEveryone loves a crosspost!
Comment #33
oriol_e9gRolled for D7
Comment #34
scor commentedthanks for the backport @oriol_e9g
Comment #35
webchickCommitted and pushed to 7.x. Thanks!