I'm creating an issue here since this has been discussed a few times (thanks to @_masaka for the reminder). Let's keep the conversation rolling here.

By default, any RDFa markup inside the body of a node will not be parsed under the RDFa 1.0 processing rules. That means that you can't handcraft RDFa in a node body: while the majority of the Drupal users will probably not care about this, some people might want to embed some RDFa in the body. This is fixed in RDFa 1.1 but there might be some work around we could consider for D7/RDFa 1.0.

- Create a separate field (to replace body, or in addition to body) which will have no RDF mapping (this is an immediate fix which requires no extra module)
- Add an option in the contrib rdfx.module to disable the content:encoded mapping for the body of a given content type (you can do that via the RDF UI module too).
- Duplicate the content of the field so that we have one version with the wrapping RDF mapping around and another hidden with no RDF mapping which will allow full RDFa parsing of the field content.

Comments

Anonymous’s picture

Anonymous (not verified) commented

Option 3 appeals to me, although I might reverse it so the one with content:encoded is the one that is hidden.

scor’s picture

scor commented

well, hiding the additional non-mapped output has the benefit that you don't need to fiddle with the default core content:encoded, just display an additional field output which is hidden via CSS.

Anonymous’s picture

Anonymous (not verified) commented

Is hidden markup used by the big consumers (i.e. Google)?

I think that the RDFa in the body might be the RDFa that people want consumers to access. For instance, they might put the RDFa for a recipe in the body to get Google Rich Snippets. If hidden markup isn't used by Google, then using a hidden field for the handcrafted RDFa probably isn't sufficient for many use cases.

Can you remind again what the function of content:encoded is in the default mapping? I know that it was something to do with RSS, but I can't remember what use case it was in reference to.

no2e’s picture

no2e commented

hidden via CSS

At the frontend?

Sites might get penalized by search engines for that. In particular, if it is so much text, wich is common for the body field. And this doubled content might get read by some screenreaders, too. Not to mention user-agents in general without CSS support.

Don't hide content via CSS (if it shall not be toggled or so).

scor’s picture

scor commented
Title: Allow for parsing RDFa inside the annotated fields » Allow for parsing RDFa inside annotated fields

Just to clarify: Initial markup (core more or less out of the box):

<div class="field-item" property="content:encoded">
  <p>the content of your body here with some RDFa...</p>
</div>

after:

<div class="field-item" property="content:encoded">
  <p>the content of your body here with some RDFa...</p>
</div>
<div class="field-item hidden">
  <p>the content of your body here with some RDFa...</p>
</div>

I'm not sure how search engines would react to hidden elements and whether or not they would ignore that RDFa as a result. We need to evaluate the risks of having some hidden content as some search engines might not like it and penalize your ranking though.

scor’s picture

scor commented

Then we're back to square one: turn off the mapping of your field and if you have no RDFa in there your field will not be annotated with RDFa.

Another alternative would be to parse the RDFa (with ARC2) from the content, and render the triples as an RDFa snippet next to the field.

@linclark: yes, content:encoded is a mapping to be similar to the RSS use case, instead of having no mapping at all and 99% of the site having no RDFa in the body.

I don't believe many people will handcraft RDFa in their field, the same way they don't handcraft the HTML code for displaying the ratings, it's too much prone to errors without an RDFa wysiwyg. We're getting there with projects like live loop though but still. Instead having specialized fields handling the RDFa is more reliable and user friendly.

Anonymous’s picture

Anonymous (not verified) commented

Another alternative would be to parse the RDFa (with ARC2) from the content, and render the triples as an RDFa snippet next to the field.

I was thinking about something like this as well, though if we hide it might still be the same problem.

Will any consumers that we know of actually use the content:encoded mapping that is in the RDFa? If not, maybe option 2 is really the best.

Anonymous’s picture

Anonymous (not verified) commented

no2e:

doubled content might get read by some screenreaders, too.

Do you know which screenreaders? When I was doing more CSS work, I was under the impression that elements with visibility: hidden; and/or display:none; wouldn't be picked up by screenreaders (which is why you had to use text-indent for stuff). That may not be the case with all screenreaders, though.

I think that Google only removes you for hidden/duplicated text after a review to see if you have devious intent, but it is something to be concerned about.

tourendal’s picture

tourendal commented

This blog post http://blog.3kbo.com/2011/03/12/drupal7-rdfa-xmlliteral/ suggests changing the doctype to RDFa 1.1 and wait for RDFa 1.1 parsers to solve the problem.

Anonymous’s picture

Anonymous (not verified) commented

I think it makes sense to optionalize this somehow. That way, there will be a flag letting the system know that this should be parsed for RDF and we can add the triples to the index for the SPARQL endpoint as well.

I think it would make sense to add this in RDF UI at the field level.

scor’s picture

scor commented
Project: Resource Description Framework (RDF) » RDF Extensions