Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
As described in the JSON-LD feature explanation, JSON-LD uses URIs for properties. In order to use JSON-LD as we want to, we need to create URIs for our fields and properties.
For example, field_tags might have a URI such as http://example.com/site-vocab/node/article/field_tags
It would be nice to use a consistent URI for certain universal properties such as UUID. However, determining which properties are universal properties and which are custom to the site is difficult. It may be better to just create a URI on the site for each term.
At the very least, we want to expose this for field instances and entity subtypes (bundles). We may also want to expose schema information for field types and entity types. These could have a subProperty and subClass relationship, which could possibly enable reasoning across sites that use the same field types.
We also need to have two vocabularies for the two supported domain models.
Proposed resolution
Base vocabulary URI
// Prefix = site
http://example.com/site-schema/
Terms from Drupal-specific domain model:
// Temp prefix = site-cs
http://example.com/site-schema/vnd-drupal/
--or--
http://example.com/site-schema/content-staging/
Entity type URIs
Common domain model:
// Entity type
site:entity/node
// Entity subtype
site:entity/node/article
Drupal specific domain model:
// Entity type
site-cs:entity/node
// Entity subtype
site-cs:entity/node/article
Field instance URIs -- primitive fields
Common domain model:
site:fields/node/article/field_body_value
site:fields/node/article/field_body_summary
Drupal specific domain model:
site-cs:fields/node/article/field_body
site-cs:field_types/text_textfield
site-cs:field_types/text_textfield/value
site-cs:field_types/text_textfield/summary
site-cs:field_types/text_textfield/format
Comments
Comment #1
scor CreditAttribution: scor commentedI had a chat with Lin about this yesterday during BADCamp, and I mostly agree. In my thesis I talked about a similar "site vocabulary" and I was using the path
/ns#as namespace, but I think it's a bit obscure and/site-schemaor/site-vocabularyis a better choice. This brings up the question of # URIs vs. 303 and httpRange-14 but I don't think it's something we need to worry about, it should work if the response describes only a particular field or content type, and we can live with the field and its representation being the same resource.Regarding the local term of the content types, fields, if you look at an old example of such site vocabulary, I was using the content type directly as local term e.g.
site:Article, but given that we want to support any entity type, we should prefix the entity type like node/ or comment/. For content types which are classes in the RDF world, the convention is to capitalize the first letter, so the machine namearticlebecomessite:Article. This might look funny coming from a Drupal perspective where all machine names are lower case. I'm not sure this really matters too much given that these classes are not necessarily going to be reused outside the scope of content staging or schema sharing. External vocabularies will definitely continue to follow that convention though (schema.org, FOAF, DC, etc.). For properties, I was only modelling the fields (not their field properties), and I was namespacing them with the content type they belonged to, for example the title field of an article wasarticle_Title. Slashes were not used because all terms were defined in the same site vocabulary document using hash URIs, but I find the slash URIs proposed in the OP more appealing.Depending on which model is used for the serialization, and for sake of simplicity, we might want to stick to just one namespace even if there is some overlap and some terms are being defined in both namespaces. So for example, when serializing in the generic model, you might use
site:entity/node/article, but when serializing in the Drupal specific model, usesite-cs:entity/node/article. This would simplify the logic of the serializer, and these terms could be generated on the fly I believe (no need to store them since they follow a predictable pattern based on the various machine names).@Lin: it might be good to show some examples of JSON-LD output using these proposed vocabulary URI patterns for both the generic and the Drupal specific models.
Edit: I think we should go ahead with the suggested patterns from the OP, as we can always rename the URIs after feature freeze, without changing the whole appoach.
Comment #1.0
scor CreditAttribution: scor commentedAdded preliminary URI structure.
Comment #2
Anonymous (not verified) CreditAttribution: Anonymous commentedI added site-cs:field_types/text_textfield.
This would be the range of site-cs:fields/node/article/field_body, and the domain of site-cs:field_types/text_textfield/value, etc.
Comment #3
Anonymous (not verified) CreditAttribution: Anonymous commentedRelated to this issue, I've posted #1831286: Provide machine-readable description of entity/field/property.
Comment #4
Anonymous (not verified) CreditAttribution: Anonymous commentedI've been rethinking this. Based on the fact that we want to expose all of the properties which have a bundle as their domain at the URI for that bundle, I think we might want to create separate types for the content staging and regular vocabularies.
For example,
EDIT: I see that scor suggested this, so we're on the same page. I will edit the proposal to reflect this.
Comment #4.0
Anonymous (not verified) CreditAttribution: Anonymous commentedAdded site-cs:field_types/text_textfield.
Comment #5
scor CreditAttribution: scor commentedAbsolutely. I don't see a good use case for aligning both vocabularies anyways, it seems to me that the two models won't be used together in the same datasets. The future will tell, but for now just having one vocabulary for each model and just using that vocabulary when serializing the data keeps things nice and simple (relatively speaking). In any case OWL offers mechanisms for achieving ontology alignment if someone needs it, but that's not on the table for core.
Comment #5.0
scor CreditAttribution: scor commentedEdited vocabulary terms.
Comment #18
smustgrave CreditAttribution: smustgrave at Mobomo commentedWith RDF since removed from core wonder if this is still a valid task?