RDF module can't handle compound fields

The RDF mapping API only provides the ability to map fields to RDF terms... the properties of those fields cannot be mapped.

yup, this is the same problem that is addressed in the Entity RDF announcement, and that's what the Entity RDF module implements (along with the entity_rdf branch of JSON-LD and RDFx). #1712982: Decide on data structure for RDF mappings includes several alternatives for defining the RDF mappings in code.

Sir,
I am very new to rdf. I have used field Field collection module. I have add file field and tag to field collection. My objective is to add tag to each file uploaded for a particular content type. In triple store field_collection_item is coming. How I can find the files and tags via the field collection in the triple store? Or how can I show files and tags in triple store. Sir, I am very new to semantic web. Will you please elaborate on the solutions you provided above?

Thank you

@go4romi could you file your support request at http://drupal.org/project/issues/rdfx or create a new discussion at http://groups.drupal.org/semantic-web please? This issue is specifically about Drupal 8, not Drupal 7 + field collection.

I'd like to suggest a slightly different approach based on the previous patches. This patch adds the possibility to have sets of attributes in the newly added _attributes in field items. _attributes becomes keyed by elements of the field formatter. Examples of field formatter elements are [street, city, zip code, ...] in addressfield, or [url, title and type] for taxonomy term link (needed in #2072791: Output RDFa markup for type + title in taxonomy term reference and entity reference formatters). The elements composing the keys of _attributes can often match the field properties, but not necessarily limited to that, for example in the case of the taxonomy term link.

Each RDF field mapping can also define a mapping for each field property (street, city, zip code ...). Example in YAML:

fieldMappings:
  field_address:
    street:
      properties:
        - 'schema:streetAddress'
    locality:
      properties:
        - 'schema:addressLocality'
    zip:
      properties:
        - 'schema:postalCode'

Compared to what we do now, we're essentially shifting from using what's directly in $mapping to $mapping['value'], 'value' being the default key found in the RDF mapping. This is the key that the field template will look for and use for its fallback attributes, and field formatters interested in other elements (street, locality, ratings,...) can inject these in their output and remove the 'value' key if they don't want to have any attributes on the field template.

I will post another patch in the sister issue #2072791: Output RDFa markup for type + title in taxonomy term reference and entity reference formatters that leverages this new _attributes array.

Can you please explain this further? It sounds like you're saying that the entities referenced by entity reference fields would have at least 2 different mappings that you would have to configure, the mapping that is stored for the bundle and the mapping that is stored for the field which points to it.

Well, assuming that the bundle of the referenced term has a mapping, we would use that. In the standard profile for example, the 'tags' bundle has RDF mappings, so when rendering the taxonomy_term reference links, we can load the mappings of the 'tags' bundle to know what attributes to inject. I posted a patch at #2072791-1: Output RDFa markup for type + title in taxonomy term reference and entity reference formatters which hopefully will shed more light on this use case.

I've had discussions about this issue with yched, catch and effulgentsia during DrupalCon, and here are the options we have talked about (in order of preference).

1. Establish a "contract" between field types and field formatters about what output properties are prepared and handed over to field formatters. Since all the output properties are common to all formatters, they ought to be defined at the field type level. For example, the addressfield field would have the following output properties:
- value
- street
- zip_code
- locality
- region
- country

Taxonomy reference field / entity reference field:
- value
- name
- url

Text field with summary:
- text
- text_trimmed

It's up to the formatter to decide to use all, some or none of the output properties in its HTML output. By default, fields would only have the "value" output property. If this value output property is still set by the time we get to the field template, then it is used to wrap the formatter markup (like it is D7 and right now in D8 after #1778122: Enable modules to inject attributes into field formatters, so that RDF attributes get output).

2. For each field formatter, implement "sister" field formatter for schema.org/RDFa for the compound fields, where the schema.org RDFa attribute would be hard-coded. This is a departure from the flexibility we're used to in Drupal. Pros: only a few field formatters would require this, not all, for example most text field formatters and simple formatters like telephone or email would not need this. Cons: some field formatters are duplicated in the field UI. For example this is how the formatter drop down for the taxonomy reference field would look like:
- Link
- Link (schema.org)
- Plain text
- RSS category
(plain text is already handled by the field template fallback _attributes)

3. Since field formatters are plugins, it should be possible to alter the method invoked for each field formatter, and the RDF module would "override" the viewElements() method of the field formatters which have compound fields in order to hardcode the schema.org RDFa attributes in the output. Pros: only a few field formatters would require this (same as 2. above) Cons: we usually avoid altering default methods in core, and leave that for custom code (or contrib in the worst case), since in the end only one module can win the alter race.

I'll work on a patch which implements the first approach.

This patch is just a reroll of #10 after the comment field patch which introduced a lot of git conflicts.

This patch implements the approach described in #14.1. To that effect it introduces the new method ConfigFieldItemBase::outputProperties() which returns the list the output properties field formatters can expect in $item->_attributes. I've implemented it for the entity reference field. The default is array('value').

This patch also fixes the EntityViewControllerTest fail.

reroll

One requirement for this issue is to have all the mappings of the field compound properties in config, which is implemented in this patch. Secondly, the RDF module has to prepare the mappings, pass them to the field formatter which have to place these attributes appropriately in the formatter output.

Compound fields have a fairly predictable mapping and therefore don't need to be made customizable in config. Addressfield for example has consistent mapping (PostalAddress, streetAddress, addressCountry, etc). The street property of your formatter is always 'streetAddress', and I would qualify any situation where this is not the case (can't think of any) as enough of an edge case to call for a custom implementation (e.g. customer formatter extending the addressfield formatter).

This issue starts to get complicated when you try to add an abstraction layer so that modules like RDF or microdata can be in charge of generating the attributes for the mappings (and possibly wrapper HTML elements), and then coordinate somehow with the field formatter. This complicated API is not necessary if you deal with the compound field HTML markup only in the formatter. From the formatters perspective, all you get from config is the $item->_attribute used to link your main content to that field (for example schema:address), and then handles the rest of the markup in viewElements(). Here is an untested hypothetical example for addressfield (inspired from current D7 code):

  $format['locality_block'] = array(
    '#type' => 'addressfield_container',
    '#attributes' => array('class' => array('addressfield-container-inline', 'locality-block', 'country-' . $address['country'])),
    '#weight' => 50,
  );
  $format['locality_block']['postal_code'] = array(
    '#title' => t('Postal Code'),
    '#size' => 10,
    '#required' => TRUE,
    '#attributes' => array('class' => array('postal-code')),
  );
  $format['locality_block']['locality'] = array(
    '#title' => t('City'),
    '#size' => 30,
    '#required' => TRUE,
    '#prefix' => ' ',
    '#attributes' => array('class' => array('locality')),
  );
  $format['country'] = array(
    '#title' => t('Country'),
    '#options' => _addressfield_country_options_list(),
    '#required' => TRUE,
    '#attributes' => array('class' => array('country')),
    '#weight' => 100,
  );
// Add RDFa attributes if this field has a mapping.
if ($item->_attribute['property']) {
    $format['locality_block']['postal_code']['#attributes']['property'] = 'schema:postalCode';
    $format['locality_block']['locality']['#attributes']['property'] = 'schema:addressLocality';
    $format['country']['#attributes']['property'] = 'schema:addressCountry';
}

One could imagine a similar example using Twig. The advantage here is that the developer writing the field formatter is in total control of the RDFa markup and doesn't have to understand another compound-specific API for each of the compound output properties.

In conclusion, I believe the RDF module should not have to handle compound fields in a different manner than it currently handles regular fields. I'd like to get my RDF module co-maintainer to comment here before closing this issue.

So you're talking about hard-coding Schema.org properties in the formatter? Unless this is in conjunction with limiting the scope of RDF module to Schema.org, I don't know how that makes sense.

Yes, it does have a bearing on the vocabulary used in the regular RDF mappings set in config, though core does not care about that. For example addressfield and fivestar should support schema.org since their use cases are supported in schema.org, and it makes sense for the RDF mapping in config for these fields to be also schema.org (schema:address and schema:aggregateRating for example, respectively). On the other hand a CreativeCommons license field would most likely use the CC vocabulary in its field formatter, and the RDF mapping stored in config for this field could be set to 'cc:license'. Likewise, a field formatter implementing some other kind of field foobar and willing to support a custom vocabulary, it should hardcode its RDFa markup in the formatter with the foobar terms, and the field mapping in config could be 'foobar:baz'. Essentially the field formatter would become vocabulary specific, which is fine as I can't think of a use case where you would want to support and offer different vocabularies for a given field. If someone was to come up with a use case, a field setting could be implemented.

As far as core is concerned, the vocabulary natively supported by the formatter does not matter, since since the mappings defined in config are vocabulary agnostic.

I should also add that core will not have to follow the approach described in my previous comment because we don't have compound fields in core. Injecting $item->_attributes inside the formatters output or leaving the field wrapper place the attributes is sufficient for all core fields.

The RDF module in core has never claimed to be able to serialize non-HTML data on its own. In D7 for example, this requires the rdfx contrib module. So yes, core is limited to HTML data. For compound field formatters to be serializable as non-HTML, they will have to provide the data as a PHP array or object which includes the same hard-coded mappings that are used in the field formatter HTML (via some hook which contrib should define). Building a API that works in both non-HTML and construct the equivalent HTML is a no-go since we want field formatter author to be able to write their own HTML. Some fields might create new resources on the fly (e.g. addressfield and fivestar) as opposed to a flat list of properties, and we don't want to lock the output structure of field formatters in any way. Also, as far as I'm aware, core entity API does not know about the output/rendered properties of fields formatters, it only knows about the input properties tied to the storage. These output properties might change depending on the formatter for a given field, and thus they should be formatter specific, not field specific.

So yes, core should remain limited to HTML data, and contrib can extend this to other formats.

Core did gives us the mappings, yes, but when it comes to compound fields, even if you had the mappings, you also need the structure of the output properties (how they are grouped, what type is the new resource, does it have a URI, if so how is it constructed). I toyed with this with entity_rdf, but it's hard to come up with a generic API that works for all use cases. It's easier to leave it up to the each individual field module to return an array/object (or a marked up HTML output), because field modules know their data model better than any other module.

We can and should make explicit that core alone is not sufficient to build an RDF model for compound fields, and that compound field formatters will be required to implement some hook or method to advertise their RDF model if they desire to be serializable.

Core should only support the HTML data and leave other RDF model serializations for contrib. By only supporting this, core does not have to worry about non-HTML RDF serializations.

Can someone comment on the status of this issue in D8?

FWIW, not being a drupal developer myself, it seems conceptually necessary to reduce a compound field into the atomic components of the schema you intend to format. Once that is accomplished, the field and the formatter (and the parser too) need to agree on both the text and semantics of the keys used to store/lookup the properties.

If you want to support multiple schemas which break down the same compound field differently, the field type cannot be the thing that defines field properties. Parser and formatter need to be coordinated such that the formatter understands the text and semantics of the keys the parser used to store properties, as it was parsing out the elements of a specific schema.

But if you're locked into a single set of properties defined on a field by the field type, it seems to me that you need to pick your poison. If you can crosswalk from the schema included in core to the schema you want to output, then great. Otherwise, formatters for alternative schemas could include their own parsers to pick out the components they need, so long as the formatter has access to the original text of the field. The only difference seems to be that the text is parsed every time it's rendered, rather than whenever it's edited. This may not be pretty, but it seems to be what is possible to do?

It may help to explicitly state the scope of this issue:

1. support in core for all possible schemas?
2. core supports decomposing compound fields into the atomic units of a preferred schema?

Overall, I agree with you @bnordgren.

support in core for all possible schemas?

Yes, even though we will use schema.org for the default mappings, the main goal is to remain vocabulary agnostic in the design of the API, and to allow you to set your own mappings from other schemas like DC, FOAF, SKOS for your entity bundles and fields.

core supports decomposing compound fields into the atomic units of a preferred schema?

Fields in core already support storing data into separate columns in the DB, and field formatters can process these atomic bits and place them however they want in the HTML output. When it comes to RDF mappings, each field will have a primary mapping, and optionally will be able to define extra mappings for its atomic parts. In the end it's a balancing act between overkill flexibility (which hurts UX and becomes error prone) and pre-built settings with less room for errors. Most of core's field types and formatters are pretty basic (they don't have that many atomic parts) so it's really in contrib that we will encounter those more complex field types.

There has been no new work on this issue in quite some time. So I'm assuming the person assigned is no longer being actively pursuing it. Sincere apologies if this is wrong.

Still a valid issue, adding need reroll tag.

This possibly could still be a valid issue.

RDF is moving out of core and into https://www.drupal.org/project/rdf

So the current solution will need to heavily be altered obviously.