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
Comment #1
Anonymous (not verified) commentedThis 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.
Comment #2
scor commentedcan 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).
Comment #3
Anonymous (not verified) commentedI 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
Comment #4
Anonymous (not verified) commentedI 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.
Comment #5
Anonymous (not verified) commentedchanging 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.
Comment #6
scor commentedSeems 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.