Drupal 7 core expresses mappings on a per bundle basis. It seems more appropriate to go down to the field level so that the RDF mapping for each field can be exported for example. It is likely that in the context of features/distributions, RDF mappings will be defined at the granularity of the field instance, and not at the bundle level, e.g featureA provides mappings for field_instance1 and field_instance2, and featureB provides the mappings for field_instance3 and field_instance4.
Idea #1 (currently implemented in entity_rdf): One array using a key of the form 'entity_type:bundle:field'. The field properties are nested inside the 'field properties' key.
- Pros: less nesting than having a nested array of entity_type => bundle => field name like we have in D7 core.
- Cons: the field property mappings are nested inside the field mappings.
'node:event:field_address' => array(
// 'rdf properties' lists the URIs of the properties used to describe
// the value of that field. These URIs come from popular schemas which are
// useful to understand the data when shared on the Web.
'rdf properties' => array('http://schema.org/address'),
// If 'rdf types' is specified, a new intermediary entity of the given
// type will be created. This is useful in the case of a field that
// is composed of several properties such as an address, and when these
// properties need to be grouped together.
'rdf types' => array('http://schema.org/PostalAddress'),
// Compound fields are made out of several field properties, which are
// listed below. Each of them can also be mapped to property URIs from
// popular schemas.
'field properties' => array(
'thoroughfare' => array(
'rdf properties' => array('http://schema.org/streetAddress'),
),
'locality' => array(
'rdf properties' => array('http://schema.org/addressLocality'),
),
'postal_code' => array(
'rdf properties' => array('http://schema.org/postalCode'),
),
'country' => array(
'rdf properties' => array('http://schema.org/addressCountry'),
),
),
Idea #2: similar idea as above except that the key includes the field property name.
- Pros: less nesting than having a nested array of entity_type => bundle => field name => field_property.
- Cons: the field itself is not grouped as nicely the idea #1, and I don't see a use case for going down as far as the field property level for defining mappings, in other words, the field property mappings really ought to belong to the same data structure of the field they belong to.
'node:event:field_address' => array(
'rdf types' => array('http://schema.org/PostalAddress'),
'rdf properties' => array('http://schema.org/address'),
),
'node:event:field_address:thoroughfare' => array(
'rdf properties' => array('http://schema.org/streetAddress'),
),
'node:event:field_address:locality' => array(
'rdf properties' => array('http://schema.org/addressLocality'),
),
'node:event:field_address:postal_code' => array(
'rdf properties' => array('http://schema.org/postalCode'),
),
'node:event:field_address:country' => array(
'rdf properties' => array('http://schema.org/addressCountry'),
),
Idea #3:: A variant of #1 where the field itself is just a special case of the field properties, maybe this is where a #-style key would be useful:
'node:event:field_address' => array(
'#self' => array(
'rdf types' => array('http://schema.org/PostalAddress'),
'rdf properties' => array('http://schema.org/address'),
),
'thoroughfare' => array(
'rdf properties' => array('http://schema.org/streetAddress'),
),
'locality' => array(
'rdf properties' => array('http://schema.org/addressLocality'),
),
'postal_code' => array(
'rdf properties' => array('http://schema.org/postalCode'),
),
'country' => array(
'rdf properties' => array('http://schema.org/addressCountry'),
),
),
Comments
Comment #0.0
scor commentedadd more ideas for structure
Comment #0.1
scor commentedadd documentation to idea #1 which is the one I chose to implement for now
Comment #0.2
scor commentedtypo
Comment #1
klausiDiscussed on DC Munich: I think we should not use the term "field properties" as "properties" is very overloaded in drupal, so I suggested "field columns" or maybe "field components"? Colums relates to the terminology used in field DB storage, but I think it would fit.
Comment #2
scor commentedWe have a winner, thanks @klausi! I like "field columns" too, that's the same terminology used in the core field API.
Comment #2.0
scor commentedcurrently implemented in entity_rdf