Currently, we attach an RDF mapping nested array to each entity. There are a number of issues with the current API.
- The mapping is attached on entity load even if it isn't used in the rest of the rendering process, resulting in a waste of processing time.
- The nested array structure can be hard to read.
- Mappings can be defined for non-fields, which means that there is a mapping for data which isn't part of our internal model.
Store each RDF mapping as a config entity (RdfMapping). This would be modelled on EntityDisplay in its API.
$article_mapping = rdf_get_mapping('node', 'article');
'properties' => array('schema:startDate'),
'datatype callback' => 'date_iso8601',
Fixes problem 1 by only accessing the RDF mappings when needed. Therefore, if a site uses JSON-LD but not RDFa, the RDF mappings would only be loaded on application/ld+json requests, not on text/html requests.
Fixes problem 2 by using the RdfMapping config entity. These can be documented clearly so that it is easier for developers to understand the configuration options.
Makes it possible to fix problem 3 by using config entity system. We can validate that a mapping corresponds to a field in the config entity validation. This is not addressed in this patch.
- Removes rdf_mapping attribute from entity
- In D7, the rdf_mapping attribute is attached to entities using hook_entity_load. It is then used in functions such as hook_preprocess_field to assemble the correct attributes array. Instead, client code should now use
$mapping_manager->getFieldMapping($entity_type, $bundle, $field_name)->get();
- Removes rdf_mapping_save
- In D7, a nested array contains all bundle and field mappings, and can be saved using rdf_mapping_save. Instead, client code should load the mapping config entity using
$mapping_manager->getFieldMappingConfig($entity_type, $bundle, $field_name)->get();, and then save necessary changes using the config API.
- Removes hook_rdf_mapping
- In D7, if a module created an entity type or bundle, it could define a default mapping for that entity and its fields. Instead, this can be handled with config files in the module's config directory.
- Removes global entity type mappings (RDF_DEFAULT_BUNDLE)
- In D7, a module could define a default mapping for an entity type. For example, all user bundles have the type "sioc:UserAccount". This kind of defaulting can cause problems, . Instead, we do not handle global entity type mappings in core. Someone can choose to support this in contrib using the MapBundleForOutput and MapFieldForOutput events.
- Changes mapping attribute names
- In D7, the mapping attributes are
rdftypesfor bundles, and
callbackfor fields. This changes to
typesfor bundles, and
datatype(remains the same), and
Original report by fago
Since we've got an Entity Field API now writing any data on an entity that is not a properly registered field is highly discouraged. Thus, we should fix rdf module to not do so, but instead leverage the new Entity Field API.
Instead of having $entity->rdf_mapping populated in hook_rdf_load() we could migrate to a computed field which uses whatever API to lazy-load the mappings whenever needed.
In addition to that I wonder whether
- we really need per entity rdf mappings? To me it looks like they are per entity type / bundle only?
- we shouldn't tie the RDF mappings solely to data types of the Typed Data API. So e.g. you configure the default mapping of a field type there. Then, we'd need to allow overrides per data, either have a totally separated API that makes mappings that refer to the typed data structure - or even have built-in support for an rdf-mapping key in typed data definitions?
I must say I like the idea of having a totally separated API that refers to the typed data API data structures more as it keeps things better separated. Thoughts?
FAILED: [[SimpleTest]]: [MySQL] Setup environment: Test cancelled by admin prior to completion. View
PASSED: [[SimpleTest]]: [MySQL] 58,689 pass(es). View
PASSED: [[SimpleTest]]: [MySQL] 58,425 pass(es). View