Description

Most fields in Drupal core have just one value and this plays nicely with the way RDF mappings are structured in core: one mapping definition (predicates, datatype, callback) per field. However some fields in contrib have several values which need to be annotated in RDF, for example geolocation, Voting API, address field.

Requirements

- multiple values per field
- optionally allow for a nested resource generation (bnode by default, but possiblity to specify a URI callback). address is a good example where a bnode is usually used to group the street, zip, city etc.
- backward compatible with the core RDF mapping structure

one level of nesting ought to be enough for most field types, generally if more nesting is needed, proper references/entities would be used.

This would allow to extend the core text_with_summary field for example to have a different mapping for its 'value' and 'summary'.

Proposal

Nest an RDF mapping array inside a #mapping key. Example using some values from the geolocation module (ignore the predicates, some are made up!):

function placemodule_rdf_mapping() {
  return array(
    array(
      'type' => 'node',
      'bundle' => 'place',
      'mapping' => array(
        'rdftype' => array('geo:Place'),
        'title' => array(
          'predicates' => array('geo:name'),
        ),
        'description' => array(
          'predicates' => array('geo:description'),
        ),
        'location' => array(
          'predicates' => array('vcard:geo'),
          '#mapping' => array(
            'lng' => array(
              'predicates' => array('vcard:longitude'),
            ),
            'lat' => array(
              'predicates' => array('vcard:latitude'),
            ),
          ),
        ),
      ),
    ),
  );
}

Another example with address field:

function organizationmodule_rdf_mapping() {
  return array(
    array(
      'type' => 'node',
      'bundle' => 'organization',
      'mapping' => array(
        'rdftype' => array('foaf:Organization'),
        'title' => array(
          'predicates' => array('foaf:name'),
        ),
        'address' => array(
          'predicates' => array('vcard:adr'),
          '#mapping' => array(
            'rdftype' => array('vcard:Home'),
            'thoroughfare' => array(
              'predicates' => array('vcard:street-address'),
            ),
            'postal_code' => array(
              'predicates' => array('vcard:postal-code'),
            ),
            'locality' => array(
              'predicates' => array('vcard:locality'),
            ),
            'country' => array(
              'predicates' => array('vcard:country-name'),
            ),
          ),
        ),
      ),
    ),
  );
}

Comments

Anonymous’s picture

This looks pretty similar to what I committed in microdata module this week. I'll be posting my patch to the AddressField queue soon.

Unless I'm mistaken, this does require changes to the field formatter so there will need to be a patch in each field queue for field formatters that need this special handling.

scor’s picture

can you point me to the commit you are referring to?

and I forgot to add to my initial post above: each multi field module should also have a way to give default predicate mappings for their values to make the job of the site admin easier in the UI, since most of the time, these mapping will not change (unless special advanced use case).

Anonymous’s picture

I committed the multiple attributes as part of this commit (it's a big commit, though):
http://drupalcode.org/project/microdata.git/commit/306e99e

And here is the commit for default mappings:
http://drupalcode.org/project/microdata.git/commit/3ba53ed

Anonymous’s picture

I had been planning to go into alpha with microdata soon and conduct some Developer Experience testing on the API... one nice thing that microdata will give is a larger audience of average Joe and Jane developers who are interested in testing the API. Fortunately, because of the similarities between the two, these users will also be testing much of the RDF API.

The recommendations that come out of that testing should be applicable to both RDF and microdata in this issue, so I'll cross post them (or a link to them) here when I've finished the testing. We can then work to align the changes so that they are as consistent as possible between implementations.

Anonymous’s picture

Title: Extend core RDF mappings to support multi value fields » Extend core RDF mappings to support compound fields

changing the name because Field API already uses multivalue fields to describe something that RDFa does work on.

Compound fields is the term I've been using to describe this issue.

scor’s picture

Seems like Lin is making good progress on the microdata API front. I've created #1268270: Identify microdata API bits which could be generalized for other RDF modules to see how we could start generalizing some this API to be useful for RDFx.