Support JSON-LD

[kopecmi8]

Node.js version:
9.8.0
npm version:
5.6.0
Strapi version:
v3.0.0-alpha.11
Operating system:
Ubuntu 16.04.4

Do you want to request a feature or report a bug?
feature

What is the current behavior?
Not implemented yet

What is the expected behavior?
I'm working on my master thesis with topic Web application for semantic data support (Semantic CMS), and I choosed Strapi as CMS that I want to extend to this functionality. I have already started worked on it, and I made some modification of your data model and your plugins.

Changes will be better saw on example. This is example of my model Event entity:

{
  "connection": "default",
  "collectionName": "event",
  "info": {
    "name": "event",
    "description": ""
  },
  "@context": {
    "@vocab": "http://schema.org/",
    "_id": "http://schema.org/identifier",
    "startDate": {
      "@id": "startDate",
      "@type": "DateTime"
    }
  },
  "@type": "Event",
  "options": {
    "timestamps": true
  },
  "attributes": {
    "name": {
      "type": "string",
      "label": "Name of event"
    },
    "startDate": {
      "type": "date",
      "label": "Start date"
    },
    "endDate": {
      "type": "date",
      "label": "End date"
    },
    "actor": {
      "type": "entity",
      "label": "Performer",
      "entity": {
        "@context": {
          "@vocab": "http://schema.org/",
          "_id": "http://schema.org/identifier"
        },
        "@type": "Person",
        "attributes": {
          "givenName": {
            "type": "string",
            "label": "Name"
          },
          "familyName": {
            "type": "string",
            "label": "Surname"
          },
          "birthDate": {
            "type": "date",
            "label": "Date of birth"
          }
        }
      }
    }
  }
}

Changes that I already made

Extend model with @context and @type

I extend each model with keywords @context and @type which is used in JSON-LD specification (https://www.w3.org/TR/json-ld/) and I properly modified Content manager plugin, which now store this two properties in each entity record. The goal is that stored data (in Mongo DB) is saved natively in JSON-LD and can be served by API as it is.

Add label to property

Second change is that i extend each attribute item with Label, which is used in administation, because attributes property name I use for semantic types.
As example I need startDate property named exactly like this, because if i want to use https://schema.org/Event entity start date property must be of type http://schema.org/startDate but in administration I want to show user another name than automaticaly generated from the property name as is in your original Strapi code.

Add new attribute type Entity

Third change I already made is that i add new attribute type named Entity.
It served only for simple 1:1 relations between two entities objects and its saved like JSON inner entities.
This is because lot of JSON-LD properties are actually another entity objects, and you dont want to serve thease objects alone and dont want to have different model for them. This funcionality is implemented like new input type named InputEntityWithErrors

Modified upload plugin

Fourth change I have made is modification of upload plugin. I modify model in File.setting.json and added in it @context and @type section similary like to other models. Thanks for this files entities are now of type http://schema.org/ImageObject. I realize that every uploaded file is not a image, and I'm working on better solution...

My future plans

Thease changes are all I have already done and they are available in my forked repository on https://github.com/kopecmi8/strapi, but I planning much more modifications in the near future, for example own plugin like Content type builder but with semantic funcionality, which will be produce semantic like models.

Unfortunately some of thease changes cannot be done only by adding new plugins, so I wonder if I need working on forked version or there is some other possibilty that you want to adopt some of thease funcionalities into your project?

[Aurelsicoko]

@kopecmi8 Wow... so much work done, I'm impressed! There are a lot of interesting ideas in your proposition especially the labels. Currently, we don't have a proper way to add labels to the administration panel.

However, I'm reluctant to put everything in our models. The models are the flattened representation of the database structure. It makes sense to define the type, the default value, the relationships, etc... but the labels are a pure front-end problematic. We already introduced the layout.json file in the Content-Manager and Users & Permissions plugins to customize the display of specific attributes in the administration panel. The labels could possibly be placed in this file as well.

To be honest, we won't implement new model definition like JSON-LD in the near future. You should probably keep your fork in your repository for your thesis. I wish you good luck and feel free to ask questions if you need!

[kopecmi8]

Hello,
I have been working on semantic version of content type builder plugin and I would like you introduce into it. Firstly I thinking that I will make brand new plugin but instead of this I made decision that I will edit the original CTB, because changes that I made will be better saw in GIT and in my situation of forked version of Strapi I can easyli upadate to the new version and in future plugin can be converted into another one by particular changes of names...

Type selection

As I last write I extend your data model with @type keyword which specify the semantic type of content type. Now in the dialog for adding and editing content type I add new filed with this @type selection. Which is actually brand new form input (InputMultiSelect) which allows you selection of multiple items and searching between them which can be usefull if list of items has hundred of items as in my case. This will be better saw on image example:

Attribute type selection on property creation

Second big change is update of attribute creation dialog. In your original version you have to only select attribute type. But if you want to have thease attributes semantics, you have to select semantic type of attribute (whici is not only form input type, but it represent meaning of attribute). In my work I have been focused only for supporting of Schema.org so you can choose attributes only from list which is made dynamicly from the selected @type at first step. Schema.org also for each property specifies range which can property has to be. For example entity type http://schema.org/Person has property http://schema.org/address and its range can be schema:PostalAdress or schema:Text.
So in my extended dialog I firstly want from users select property type, than range (if property has multiple ranges) and by this selected range I filter the attribute types so user can select only attribute types which match the correct type. I guess this changes will be better saw on image example again

In case of easy attribute types like Text, E-mail and so on, I only made change that name of property is saved into the label filed in model params as I suggest last time. (there I did not ignore your suggestion for using of layout.json, but this was easies way for made working prototype...)

Relation attribute type

But big changes was made in Relation dialog. There I have to filter the list of targets content types by the @type and selected range of attribute. For example if I have property schema:address and choose range shema:PostalAddress in relation dialog I can show as target content types only types withc @type schema:PostalAddress. But this changes can result that no one target content type with spcific @type exists. So I have to edit relation dialog and if there is no one available content type of suggested @type, there is only button for creation of new content type with prefiled @type.

Next extension of this dialog is, that relation has to be mapped on inversed attribut in target entity. So I added selection field where are dynamically loaded properties from target entity which has range of @type same as entity whose relation came from. Again example image for ilustrating purpose.

Creation of Entity attribute type

Last time I told you about new attribute type Entity for inner content types. For this type of attribute I have to create a brand new dialog. In this dialog is select field which allow you to select multiple properties from entity type which you want to inner to. This selection generates dynamic form for each property where you can specify Label, Range and also attributy type. In that case you cannot select attrbiute of type Entity and Relation, because it would be too complicated.

As result of this proccess you can get form which looks like this:

As you can se I also add form input for URL attribute type, it is only simple copy of Email attribute, but wich validation with regex on URL address pattern.

Output in different format

Last change which worth mentioning is changes in Generate api plugin. I little bit modfiy generated controllers which nows allows you to publish your content also in N-quads format. You can get it by specifing Accept header in your request to application/n-quads.

Resolution

I know you have another prioerities in your Project, but I think some of thease changes can be beneficial even for non semantic purposes. My code is now in alfa stadium and lot of cleaning things has to be done, I am now in time presuare because of deadline of my work. But if you be interest in some of this ideas let me know. I still think if you adopt little bit of this changes in your core this semantic version can coexist next to the original version without big worries from next version updation and can serve for lot of users becase there is not a lot of semantics CMS.

[Aurelsicoko]

I'm very very impressed with the work done! Congratulations 👍

I can clearly understand the benefits for everyone. It allows to easily group field into an entity. I would love to merge this work but we need to update the UI because most of the users might don't need this and the UI has been complexified for everyone.

I think you should use the list fields view to create the entities. Then, each field could be drag & dropped to define the structure (could be at the root level or nested into an entity). In any case, this work has to be done because in the future we should be able to re-order the fields. I think it could also simplify the Add a new field.

The workflow for a user could be:

1. Create all the necessary fields.
2. Order them, and create an entity to group these fields together (optional)
3. Save.

So it won't break the current user experience but it will add a new step for the people interested.

Also, I'm not sure to understand why do we need to create a new entity in the relation modal? I would like to have more explanations on this part...

Again, thanks for sharing this with us, it's a great work. I'm excited to know how we could integrate some parts of your work in the existing project!

[Aurelsicoko]

I really appreciated the work done here! It helped me a lot to understand new usages and how we could improve the Content-Type Builder plugin in the future. Unfortunately, we won't implement JSON-LD support for now. Thank you @kopecmi8 for the great work 👍

[Davidhidalgo]

Wow, that was huge, I'm exploring another approach to do this... I just need time :(