building RDFa support on centralized metadata [#575508]

This is builds upon the work of #493030: RDF #1: core RDF module on top of #551406: Centralize entity properties meta data - so we can avoid having a lot of duplicated metadata (tokens, rdf, rules, ..).

Changes:
• The RDF mapping is added to the property-info of hook_entity_info(), so the separate hook is gone.
• For now I documented the attributes added to hook_entity_info for describing the rdf mapping by using the function rdf_entity_info_attributes() - as it adds stuff to hook_entity_info(). Not sure what's the best way to document this.
• For specifying a RDF mapping for the current page a page entity got introduced, which defines the default mapping. For altering that rdf_alter_page_mapping() is used. Also the uri of a page can be altered by altering $page['#uri'].
• Fixed namespacing of all functions in rdf.module.
• As previously, there is a function to get the rdfa properties: rdf_attributes(); which makes use of the property wrapper. Thus it automatically makes use of the specified mappings in hook_entity_info().
• The patch implements node and user attributes, as well as field support.

Advantages:
• rdf_attributes() is capable of generating all necessary attributes also 'rel' and 'resource'. Think of generating attributes for referenced nodes? -> Having the property info in place, just use the function. That's possible as the property wrapper can easily retrieve URIs of referenced resources.
• Avoid duplicated code like callbacks for getting data.
• Easily add more RDF, when properties are added in for tokens, just specify a mapping and you are done.
• A contrib could even autogenerate a RDF-Scheme for fields and/or allowing users to choose a mapping that make sense. (As we know the property type, we can restrict the list of possible properties by the allowed rdfs:range).

Patch attached, it's dependent on the latest patch from #551406: Centralize entity properties meta data.
For adding wrapper spans it currently uses the approach described in http://drupal.org/node/574954#comment-2033772.
A sample RDFa output of it can be found at http://drupal.org/node/493030#comment-2033900.

Comments?

Comment	File	Size	Author
#12	rdf_all.fixed_.patch	178.54 KB	fago
#12
#10	rdf.fixed_.patch	37.59 KB	fago
#10
#9	rdf.patch.txt	37.46 KB	fago
#5	rdf.patch.txt	30.17 KB	fago
	rdf.patch.txt	27.45 KB	fago

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

jpetso CreditAttribution: jpetso commented 13 September 2009 at 03:15

resub.

Comment #2

scor CreditAttribution: scor commented 13 September 2009 at 07:38

thanks for creating this separate issue. I need to look more closely at your patch. Could you tell us whether your approach helps us to deal with the theme layer issue we encounter in the current RDF patches?

Comment #3

fago

German

Vienna

CreditAttribution: fago commented 14 September 2009 at 09:49

Well it's just a different source of rdf-mappings, so the problem of how to get the RDFa attributes output stays the same. However as noted above, to prevent un-removable span wrappers I used the approach I described in http://drupal.org/node/574954#comment-2033772 - so the wrapped spans are created once the themer uses render() for #markup elements.

Comment #4

Scott Reynolds CreditAttribution: Scott Reynolds commented 14 September 2009 at 15:06

Why use base_path for user uri and not for the node uri? and if is supposed to be an absolute, we should use url() for it

/**
 * Helper function to create a URI for the user object.
 */
function _rdf_generate_user_uri($user) {
  return base_path() . 'user/' . $user->uid . '#this';
}

/**
 * Helper function to create a URI for the node object.
 */
function _rdf_generate_node_uri($node) {
  return url('node/' . $node->nid) . '#this';
}

Any chance we can remove these one line 'helper' functions.

Comment #5

fago

German

Vienna

CreditAttribution: fago commented 14 September 2009 at 20:53

File	Size
rdf.patch.txt	30.17 KB

Indeed, thanks. Also we should use url() to add the fragment - fixed that. However we cannot remove those functions as they serve as callbacks to get the uris. I fixed it to mention that in the doxygen. Furthermore I improved uri generation, so that fieldable entities may specify the path they use for viewing (node -> 'node', term -> 'taxonomy/term') and auto-generated the URI. So we have URIs now for all fieldable entities except vocabularies.

Apart from that
* I fixed rdf_date_iso8601() to work properly with timestamps.
* Changed the 'resource' attribute to be added by default when using 'rel' - as I think in the common case it's going to be needed to specify the correct URI.

Comment #6

sun

German

Karlsruhe

CreditAttribution: sun commented 15 September 2009 at 23:09

+++ includes/form.inc
@@ -2508,7 +2508,11 @@ function theme_textarea($element) {
 function theme_markup($element) {
...
+    $output = '<span ' . drupal_attributes($element['#attributes']) . '>' . $output . '</span>';

drupal_attributes() already adds a leading space for you.

This must be a DIV, because we do not know whether #markup contains any HTML block element. In XHTML-Strict, HTML block elements cannot be wrapped with a SPAN, only with a DIV.

That said, if you wrap any output in a DIV, then any output will be displayed in a block element. To circumvent this, you'd need to apply a CSS class that cross-browser-consistently reverts that DIV into an invisible SPAN -- which not always works out as it should (as we all now from our god-blessed .resizable-textarea....)

Hence, I doubt that this (too generic) approach is doable.

+++ modules/node/node.module
@@ -1112,8 +1112,8 @@ function template_preprocess_node(&$variables) {
+  $variables['name']      = array('#markup' => theme('username', $node));
+++ modules/node/node.tpl.php
@@ -12,9 +12,10 @@
+ * - $name: An array containing themed username of node author output from
+ *   theme_username(). Use render($name) to print it.
@@ -84,7 +85,7 @@
+              array('!username' => render($name), '@datetime' => render($date)));

theme_username() should take over proper handling of attributes, so $name stays $name without render(). This approach would lead to an additional wrapper element, which is technically not required and makes theming much harder.

+++ modules/rdf/rdf.module
@@ -0,0 +1,216 @@
+  // Add in property mappings.
+  $rdf_keys = array_fill_keys(array('rdf-property', 'rdf-value', 'rdf-datatype'), TRUE);

The result of this little bit strange-looking construct is not used anywhere.

This review is powered by Dreditor.

Comment #7

fago

German

Vienna

CreditAttribution: fago commented 18 September 2009 at 10:27

thanks for that good review!

@wrapping tag:
I fear we need the wrapping tag for rdfa anyway and as we never can know what a themer changes theme_username() too, I think we have to go with the div wrapper. Were the troubles caused directly caused by the "display:inline" css? Do you have more details here?

@render($name)
Well the idea was to have that wrapping element, thus the themer can remove the attributes without having to grok which theme function adds it and overriding it, also see #574954: Add theme_timestamp for RDFa?. What do you think would be the best way to go here?

Comment #8

aaron CreditAttribution: aaron commented 21 September 2009 at 18:18

subscribing, with an eye towards file metadata/rdf integration

Comment #9

fago

German

Vienna

CreditAttribution: fago commented 24 September 2009 at 18:17

File	Size
rdf.patch.txt	37.46 KB

As discussed with scor, I changed the patch so that the data-providing module also provides the RDF mapping. Thus, the remaining module does nothing more than outputting RDFa - so I renamed the module to "RDFa".

@wrapper: I changed it to use a inline div-wrapper for now. It's still added in by using #markup elements, which are then rendered in the template (e.g. see the node date). Opinions on that?
The only alternative I see here is to add the wrapped tag directly to the output string, maybe in a theme function. But then it's complicated for themers to remove it...

@sun

theme_username() should take over proper handling of attributes, so $name stays $name without render(). This approach would lead to an additional wrapper element, which is technically not required and makes theming much harder.

Well in that case it's required, the attributes of theme_username are used too, but we need another wrapping div in that case to specify the relation properly.

@patch:
I added basic support for comments and terms. So for comments the title, body and the body are annotated, as well as the relation to their node and to a possible parent comment. For those I'm just creating not visible <a> tags, thus serving just as rdfa_reference. (see rdfa_reference()). For terms the relation to the node as well as the term name is annotated.
Update: I completely forgot to mention, the patch also adds multi-value support for fields. (building upon the latest patch from #551406: Centralize entity properties meta data)

Comment #10

fago

German

Vienna

CreditAttribution: fago commented 29 September 2009 at 20:28

File	Size
rdf.fixed_.patch	37.59 KB

Slightly improved rdfa_attributes() and moved the general RDF-date mapping to system module, thus the rdfa module is really only about output.

Comment #11

29 September 2009 at 20:40

Status:

Needs review

» Needs work

The last submitted patch failed testing.

Comment #12

fago

German

Vienna

CreditAttribution: fago commented 30 September 2009 at 21:31

Status:

Needs work

» Needs review

File	Size
rdf_all.fixed_.patch	178.54 KB

The patch depends on #551406: Centralize entity properties meta data so of course it fails to apply without it. So here is a combined patch, including both patches. Bot chew on that.