During a fresh installation, I tried to create a sample rdf bundle so I went on creating one without assigning all properties apart from the rdf_type, bundle predicate, title, owner, and created/changed mappings.
I was able to create an entity like this, but when I tried to edit it - without changing anything - I got the following error message

This kinda relates to the translations I think. I assigned all mappings and created a new entity which I was able to edit normally but I still couldn't edit the faulty ones.

Also, I think that in the creation form, we can add some descriptions to provide some ideas for default values on the mappings, like the created and changed dates, can be by default dates. The title, can be by default a translatable literal and so on, so that a new user can get a small idea of the type mappings.

Drop support for Drupal 8.6.x.

The main thing this module is providing, the most important file, is RdfEntitySparqlStorage and the entity query. If I'm asked what this module does and I have to use only one phrase, I would say:

Provides an entity storage class that allows an arbitrary Drupal content entity to use a SPARQL backend. Period.

Form this perspective the rdf_entity entity type is only a use-case of this module. Given all these, I'm proposing:

1. The rdf_entity should be moved into a separate sub-module. It can be used directly or only as a good example.
2. The main module should be renamed. Probably to rdf_storage?
3. All references to applications that are using this module should be removed.
4. Fix & Move the webprofiler logic in a submodule to be enabled only on dev environments

In #7 a workaround was added in order to allow the field storage config update the a field storage when there is no mapping yet (usually when the field is first created). This is a temporary workaround and the following need to be implemented instead:

• The workaround should throw an exception instead of throwing an error. There should not be any case of a query running for an unmapped field.
• In rdf_entity_form_field_storage_config_edit_form_alter, a new #validate entry should be unshifted (array_unshift) so that it is thrown before the storage config validator. The new validator should update teh new mapping in the field handler service for all bundles or for the bundles applied to the field if possible.

The above will allow the storage form to work properly and also ensure that no wrong queries are running.

Drupal 8.5.x to end security support with May 1, 2019, according to https://www.drupal.org/core/release-cycle-overview. In the same day 8.7.0 will be released.

We should stop testing w/ 8.5.x and add 8.7.x. and maybe 8.8.x which is now the core development branch.

In #107 the "edit" operation was deprecated for entity access checks. This should be removed before we release 8.x-1.0-beta1.

This project started initially as a module in https://github.com/ec-europa/joinup-dev project but now is a standalone project. Remove any reference to Joinup project.

Add the module and sub-modules in its own "RDF Entity" package. Now it's in "Custom".

In \Drupal\taxonomy\Plugin\EntityReferenceSelection\TermSelection::getReferenceableEntities we are having the following piece of code:

if ($terms) {
        foreach ($terms as $term) {
          if ($term->parents[0] === '') {
            $parent_name = $term->label();
          }
          else {
            $options[$bundle][$parent_name][$term->id()] = str_repeat('-', $term->depth) . $term->label();
          }
        }
      }

The line where dashes are added is adding a number of dashes to each term depending on its level.
The ::getReferenceableEntities however is not meant to generate a list of options for a widget as there are no information on the widget itself or if it is used in a form, called by one or simply used in the code. Thus, it is enforcing a dash to anywhere that the terms might be queried. This is not really flexible. Remove the str_repeat.
I tested this locally and the sub options are still placed with a small indent so the default behaviour is acceptable already.

I'm getting this in logs:

User deprecated function: Passing in the "edit" operation to RdfAccessControlHandler::checkAccess() is deprecated in RDF Entity 8.x-1.0-alpha19 and will be removed before 8.x-1.0-beta1. Pass in the "update" operation instead. See https://github.com/ec-europa/rdf_entity/issues/110 in Drupal\rdf_entity\RdfAccessControlHandler->checkAccess() (line 23 of web/modules/contrib/rdf_entity/src/RdfAccessControlHandler.php)

Make \Drupal\rdf_entity\Entity\Query\Sparql\Query::setGraphType() return $this in order to allow method chaining. Consider adding a dedicated interface for SPARQL entity query class.

After a discussion today with @sandervd and @brummbar we came up with the following template/suggestion so that remarks can be added and a complete solution can be created.

Purpose of the issue: Support revisions

Current state and problematic pieces

A bit of history

Rdf entity provides a layer to support storing entities directly in the triplestore. The idea behind it is that every property of every field has a predicate URI mapped to it and this is used as a storage identifier for the database. Properties without a mapped URI do not get stored in the database and are simply skipped.
The other major factor of the module is that it uses graphs in order to store the entities separated by bundle. That means that each bundle has its own graph, rather than each entity type. This approach, while seemed nice at first, is not ideal as one cannot enforce that all objects (entities) that have a "specific schemantic meaning" will live under graphs split by their type.

Where the problems start

The last major factor - Triplets

The last major factor in our decisions is the triplestore (or quadstore as we use it) itself. A triplestore means that everything is described using triplets. This has advantages and disadvantages but what is really important for us is that it lacks a bit of flexibility against SQL in terms that you cannot have more than 3 "columns" to describe something.
For example, in SQL, for each field, you have a table where each entry stores the entity_id, the revision_id, the delta, the value and other properties required by each field. That means that a structure is created and you store one entry for each delta of each revision of each entity.
In SPARQL however, you need to find a way to do this in triplets without breaking the structure of the entity, allowing to query properly (so no serialized cheats) and without breaking the ontology (keep a predicate per property). That means that you had to do something like

entity1 field1 en-uk
entity1 field1 0
entity1 field1 test_value
entity1 field1 en-us
entity1 field1 2
entity1 field1 test_value2

Only by looking the above, the problem already exists since if you query for the field1 of entity1 you already don't know which property belongs to which delta. The sequence of the data stored is also not a way to distinguish as triplestore does not return results or stores them as you give them.

While the delta specific problem is for another issue, this remains here for the following sections.

The string ID

One of the thing that makes the scemantic web so appealing is the identification of its objects (or entities) by a unique URI. For us, that means that unlike nodes, we are using URIs for identifying the entities. This also brought up many issues in the past, as many modules did not yet support the string IDs but we got over that. Why is that important here though?
Back a year and a half, we also had to somehow support multiple versions in the Joinup project. As it is normal, the idea to support revisions just like core does was one of the ideas. However, there were a few issues here:

• The fact that we are using a graph per bundle, means that all properties were to reside under the same graph.
• Scemantic web is a way of describing entities. For the triplestore (or quadstore) that we use, that means that each property can have a triplet of properties to describe it. As it is described in the previous section, that means that since all versions of the entity would share the same URI, the entities themselves would have no way of distinguishing which property belongs to which version.
• Different IDs cannot exist for the same entity so an entity with ID http://example.com/rdf/1 cannot automatically have http://example.com/rdf/1/version/2 as the implications are multiple. The same id can be the same id of another entity (not a revision) and the queries would be a nightmare if we had to concatenate ids.

Rdf Draft

That is when the rdf_draft module came into play. The need in Joinup was that only up to two revisions can exist at any given time, a published and an unpublished one. Since the need for a history of changes was not a requirement, the solution came with the graphs themselves.
For each bundle, a second graph was created, separating the two entities and giving the option for a publication status on the entity. For us, those graphs took the form of http://joinup.eu/<bunlde>/[published|draft].
This is already a solution to many of the needs that might come up but that also came up with some limitations:

• The fact that we were already split bundles of an entity type in graphs means that we have to take care of many parameters when we try to perform CRUD operations on entities residing in specific states (i.e. we don't only query on entities in specific states).
• Workarounds had to be implemented also for other cases like supporting search_api natively.
• Limitations of states of an entity. While it covered the cases where 2 versions exists at the same time, it took a lot of work to only support once more, and while not the same effort is needed for any subsequent version, it still requires manual work in terms of development and quite a good understanding of the overall module in order to add any more. Even enabling the draft version requires a bit of manual work and understanding.
• The number of versions is finite. The idea that we are manually adding a new graph for each new state that we want our entity to have, means that we can only create a specific number and that this number is not automatically scalable. Revisions is a no go for this module.
• Split of the entity. Manual intervention is needed in order to query all versions. All graphs must be added in the query to allow querying them all. And that is regardless of whether a field is used like the moderation status field.

Revisions

The idea behind supporting revisions involves a few ideas, parameters and a couple of compromises:

• Since we are going to support such a major issue, it has to be done in a way that is split from the main module, so that the main module can work independently.
• We are going to try and mimic the node revisions system as much as we can so that we can follow best practices as well as make it a bit more understandable to users.
• We are still going to split entities under specific graphs, however, we are going to make it simpler

Drop of the rdf_draft module

The rdf_draft module is a nice implementation but should be a legacy of the past. Apart from the fact that a lot of issues have come up due to the multiple graphs we need to support, it will directly conflict with the implementation of revisions.

Graph structure

Following the problems above, we are going to drop the support of a graph per bundle and follow the notion of the Drupal entities in version 8. Each entity type has a table which stores the base fields of the entity. Unlike Drupal, however, we are going to have everything within a specific graph.
Without addressing the revisions yet, that means that every entity type will only have one graph to look into for anything.

Revisions

Revisions, like rdf_draft, will reside in a separate module. That would require the need that the storage class (or entity class) will be overridden by the new module in order to support new methods like the ::allRevisions() (corresponding to the ::allRevisions() from the NodeStorage class).
However, since we are trying to split the rdf_entity module already, we can use this module to simply include an interface and a revision trait for each entity type that is defined and wants to use the revision system.

How issues will be addressed

For all the above issues, during the discussion we came up with the following structure details.

Revision graph

The revision graph will also belong to a specific entity type, it can be defined in the annotation of the entity type or in the mapping entity that we currently support. Each entity type's graph will be solely for internal use and should not be exposed if there is an exposed endpoint.
The name of the graph is user defined.

Identification of the entities

The revision graph will be a pool of data from all revisions of the entities. As nodes do, even the current revision will exist in the graph.
Since we define that revision graphs are solely for internal usage, the IDs of the entities can be arbitrary and different from the original IDs. This gives us the ability to create IDs like http://<random alphanumeric string>.com/<entity type>/revision/<revision serial id>. The serial number can be global or per entity. If global, since triplestore does not have serial numbering, it has to be stored in Drupal or be determined on the fly when a new revision is stored. The later is a better solution solely because migrating data will not break the structure.

Connection with original entity

The idea is that the revision entities will use a property like the dcat:isVersionOf to link to the original content. Possible implications here is that the original entity might already have a property mapped to the dcat:isVersionOf predicate so probably another property might be used. Something like <base_url>/drupalIsVerionOf.
Additionally, the revisions sub module can define to all entity types that have a revision graph defined an additional base field mapped to something like <base_url>/drupalRevisionId which also maps back to the current revision ID.

Additional properties

Every revision should include the following properties apart from the drupalIsVersionOf:

• Revision ID. The idea is that this is the serial number that will also be used to construct the revision url.
• Revision timestamp. This will be used to determine when the revision was created and the order of the revisions.
• Revision updated. As with node revisions, this can be used by constraints to determine if the revision can be edited or another revision has been updated more recently.

Drop support of states

RDF Draft enforces the idea of states within the rdf_entity module. However, the revisions is not necessarily the entity in a different state rather than a history of it. Further support by states can be attained but this will be irrelevant to the rdf entity structure and only relevant to the corresponding status field.

Conclusion and Compromises

• While the idea to limit objects of a certain meaning under a specific graphs is already marked as not ideal, we can, in an organizational level, decide so. Keeping entities of the same ontology within a certain graph certainly could not always be the case but for sure keeps content a bit more organized and makes it more flexible to query and use.
• With these changes, we might need a new version. If so, it might be tough to have an upgrade path from version 1 to version 2 and Joinup might be stuck with version 1 at least for a while.
• The above description surely is far from what we have currently in Joinup but would also solve all issues that we had to support in the past in Joinup.
  ** All queries can be supported by default.
  ** Entities existing in the published graph can be simply moved over to the main entity type graph and the update path is complete.
  ** Enabling revisions only require to copy over the version of the published graph over to the revisions graph.
  ** Upgrading from rdf_draft only requires to create a new revision in the revisions graph.
  ** Support to the federation is easily achievable by having a new adding a state in the status field which is 'federation' (other statuses are published or unpublished, this is not about the state_machine state field we are using). Entities with the federation status are simply prone to becoming the new revision of the entity.

The \Drupal\rdf_taxonomy\TermRdfStorage::loadTree method is using the following hardcoded query to load the terms:

SELECT DISTINCT ?tid ?label ?parent
WHERE {
  ?tid ?relation <$concept_schema> .
  ?tid <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2004/02/skos/core#Concept> .
  ?tid <http://www.w3.org/2004/02/skos/core#prefLabel> ?label .
  FILTER (?relation IN (<http://www.w3.org/2004/02/skos/core#inScheme>, <http://www.w3.org/2004/02/skos/core#topConceptOf>) ) .
  FILTER (lang(?label) = 'en') .
  OPTIONAL {?tid <http://www.w3.org/2004/02/skos/core#broaderTransitive> ?parent }
}
ORDER BY (STR(?label))

Now that the mapping entities are in place, the predicate (the ?relation variable) can be predictable and the rest of the properties are not restricted. The terms don't need to use the http://www.w3.org/2004/02/skos/core#broaderTransitive to designate the parent.

Remove deprecated code

From the README.md:

As the module is in alpha, we're not providing any update path but we recommend to follow the next steps in order to update a server in production:

I see that this module is in alpha, but:

• oe_content (stable) requires rdf_skos (0.x).
• rdf_skos (0.x) requires rdf_entity (alpha).

I assume that rdf_entity module is used primarily within the openeuropa ecosystem.
Any oe site that wants to upgrade to D9 will have to deal with this upgrade.

The readme already offers some instructions, but I think the module needs to fully commit to supporting the upgrade.
I had some problems, which I can open separate issues for. Here I am mainly asking to make this a goal we should aim for.

Implement argument replacement for:

• \Drupal\rdf_entity\Database\Driver\sparql\Connection::query()
• \Drupal\rdf_entity\Database\Driver\sparql\Connection::update()

This is not easy as the core drivers are deferring this operation to \PDOStatement::execute() but PDO doesn't have any API that exposes the compiled query. We need to build a routine to perform the arguments SANITIZATION and REPLACEMENT.

Hints:

• Search for a library/code snippet that is doing the sanitization and mimics PDO
• Research in the source code of PDO and replicate in PHP the same process.

We are currently experiencing some failures with the upcoming Drupal 8.6. We should fix these problems and ensure to get passing tests before 8.6.0 is released. This is currently scheduled for September.

• #53 Database connection class not found in Drupal 8.6.x
• #54 Configuration name does not match ID error on Drupal 8.6.x
• #57 Enable testing on Drupal 8.6.x
• Remove the allow_failures section from .travis.yml once we get a green test on 8.6.x.

Upon installing the test module, you get this error:

The configuration name "field.field.rdf_entity.mutlifield.field_bool" does not match the ID "rdf_entity.multifield.field_bool"

Probably another 8.6 issue.

Convert the 'graph' base field into an entity reference field as it targets an entity of type rdf_entity_graph.

It would be better to make the form alter use a #tree instead of the current way of concatenating strings inside rdf_entity_form_field_storage_config_edit_form_alter().

Follow up from comment in #60

Instead of linking to the URL for creating a new RDF bundle, the link used is for creating a new node type. Probably a copy-past error.

The fix is very simple, just switch out the URL to the correct one inside RdfTypeListBuilder.

Original post (from https://www.drupal.org/project/rdf_entity/issues/2892361) from @pfrenssen:

I have a problem with a single value field from the Cached Computed Field module. The field is used to store data that is retrieved from a third party REST API, along with an expire time when the field needs to be refreshed . The field has two properties: value and expire which both are integers. I have mapped the value field to be a http://schema.org/userInteractionCount and the expire field is a http://schema.org/expires.

When I populate this field on an entity and save it everything seems to work fine. However when I load the entity again, then the field suddenly contains two items, one containing the value and the other containing the expire:

Array
(
    [0] => Array
        (
            [expire] => 1499188290
        )

    [1] => Array
        (
            [value] => 2
        )
)

The expected result is to have a single field item containing both properties:

Array
(
    [0] => Array
        (
            [expire] => 1499188290,
            [value] => 2
        )
)

Some minor changes..
Follow-up to idimopoulos#3 and idimopoulos#4 by @golddragon007
(I like to have issue number for my commit messages)

Please merge idimopoulos#4 first!

Related to #141

This is problematic when a vocabulary has many many terms.

Hi there,

Recently we have tried to bring new major changes to our modules (we use openeuropa module rdf_skos and many other dependent on rdf_skos). In this module:
https://github.com/openeuropa/rdf_skos
there is a description of the three step deployment process to bring new refactored rdf_entity and sparql_entity_storage changes.
In one of the steps, after we upgraded rdf_entity to a latest version, we ran drush updatedb and face the following issue:

[notice] Update started: rdf_entity_update_8004
[error]  modules/contrib/address/config/install is not a directory. 
[error]  Update failed: rdf_entity_update_8004 
[error]  Update aborted by: rdf_entity_update_8004 
[error]  Finished performing updates. 

The problem is that in the rdf_entity.install file in the update 8004
the

$file_system->scanDirectory

is used and according to the drupal manual if the method cannot find a directory it throws an exception which breaks the whole update pipeline.
And the reason why it cannot find a directory is because install and optional folders are not mandatory when building a module.

I would provide a Pull Request but I have no access.

Anyways the fix is simple:

foreach (['install', 'optional'] as $sub_path) {
  $config_files_path = "$extension_path/config/$sub_path";
  if (is_dir($config_files_path)) {
    foreach ($file_system->scanDirectory($config_files_path, $file_pattern) as $path => $file) {
      $new_config_candidates[$path] = $file->name;
    }
  }
}

Regards, Sergey

\Drupal\rdf_entity\Plugin\pathauto\AliasType\RdfEntityAliasType::batchUpdate is built according to the parent ::batchUpdate method. However, there is an issue with this approach as it might miss some orphaned cases.
The parent method creates a joined query where both aliases and entities are in the same result. Since this is not possible with rdf entity, we should probably not follow the same approach.
As discussed today with Sander and Francesco, we will load the complete list of rdf entities and store it in the context while checking the array so that we can easily create diffs and intersects to derive which entities need update.

This will also fix the issue that we are currently facing with the number of ids that exist in the site. We cannot request entities that have an alias already because the number of entities are a few thousands and concatenating 4k uris in an http request probably hits a limit.

In https://github.com/ec-europa/rdf_entity/blob/8.x-1.x/modules/rdf_taxonomy/src/TermRdfStorage.php#L285 the query starts with
SELECT DISTINCT ?tid ?label ?parent ?weight
However, a few lines above there is some logic performed for whether the weight is mapped and if it is, a $where variable is added.

If the weight property is not mapped, the condition to query for the weight is not added which results in a malformed query.

The scope of this ticket is to add an extra condition that handles the select part of the query.

When trying to create a new bundle, the following exception is thrown:

The website encountered an unexpected error. Please try again later.
TypeError: Argument 2 passed to Drupal\rdf_entity\Entity\RdfEntityMapping::loadByName() must be of the type string, null given, called in modules/contrib/rdf_entity/rdf_entity.module on line 203 in Drupal\rdf_entity\Entity\RdfEntityMapping::loadByName() (line 271 of modules/contrib/rdf_entity/src/Entity/RdfEntityMapping.php).

Drupal\rdf_entity\Entity\RdfEntityMapping::loadByName('rdf_entity', NULL) (Line: 203)
rdf_entity_form_alter(Array, Object, 'rdf_type_form') (Line: 501)
Drupal\Core\Extension\ModuleHandler->alter('form', Array, Object, 'rdf_type_form') (Line: 830)
Drupal\Core\Form\FormBuilder->prepareForm('rdf_type_form', Array, Object) (Line: 272)
Drupal\Core\Form\FormBuilder->buildForm('rdf_type_form', Object) (Line: 74)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
call_user_func_array(Object, Array) (Line: 153)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 657)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

This is because in rdf_entity_form_alter we are trying to load an rdf entity mapping object even if the bundle is now being created.

This is easy to fix by checking if the entity is new.

Integrate configurable fields in the rdf_entity_mapping entity. Now they are spread in the field storage configs. We may consider to add them in the bundle rdf_entity_mapping entity so we know that all mappings are stored in a single centralized place.

Next methods should be improved:

• \Drupal\rdf_entity\Entity\RdfEntitySparqlStorage::loadFromStorage(): Address the @todos. Note that we can use ::idExists() somehow to avoid loading entities from all the graphs. But this still needs profiling because ::idExists() is making additional queries.
• \Drupal\rdf_entity\Entity\RdfEntitySparqlStorage::processGraphResults() needs some love to make it more readable. Probably it needs a helper method.
• Review also allhelper methods used by these 2.

From #141.

When upgrading a website to Drupal 9, with new version of rdf_skos, following the instructions from rdf_skos readme and rdf_entity readme, the following problem occurs in updb:

system_post_update_entity_revision_metadata_bc_cleanup() fails, because "Drupal\rdf_entity\Entity\RdfEntitySparqlStorage does not implement Drupal\Core\Entity\ContentEntityStorageInterface".

Debugging reveals that the exception is thrown in Drupal\Core\Entity\ContentEntityType::checkStorageClass().
At this time, the old definition of rdf_entity entity type is still stored in the key_value table, with its old storage class, which has since been removed.

Of course the "does not implement ..." is slightly misleading, more accurate would be "does not exist".

I wonder what we need to do here.
Some ideas:

• Provide a stub storage class RdfEntitySparqlStorage extends SparqlEntityStorage to prevent the class-not-found error.
• In an update or post-update hook: Destroy the entity type, then recreate it using the new storage engine. This would lose stored data.
• In an update or post-update hook: Convert the entity type to use the new storage engine, while preserving entity data.

The main use case we want to support here is for rdf_skos and oe_content, which unfortunately did not respect the alpha status of rdf_entity. In this use case, the rdf_entity entity type does not really matter. So losing all data in rdf_entity it would be ok?

The Query::addPager() method initializes the pager regardless of whether it's needed or not.

I've encountered this issue only when altering an RDF query and applying some conditions. For example, the main RDF entity list builder query would show the pager if the query is altered and there are only a few results.

Hi, I'm working with OpenEuropa and I have the whole system build and installed (drupal-site-template, all the contrib modules of oe_*, four containers (web, database, sparq, selenium), docker, docker-compose, etc.
All seems working fine, but I have a problem in some sections... For me, the problem begins with a click on Content / RDF listing:

Then, Drupal crashed and gives:

"The website encountered an unexpected error. Please try again later.
TypeError: Return value of Drupal\rdf_entity\RdfGraphHandler::getEntityTypeGraphUris() must be of the type array, null returned in Drupal\rdf_entity\RdfGraphHandler->getEntityTypeGraphUris() (line 164 of modules/contrib/rdf_entity/src/RdfGraphHandler.php)."

Come back and go to admin/reports/dblog and seems just a problem with a module called “rdf_entity” :

Ok, I'm going to see the family of RDF Entity:

And when click in the Rdf Taxonomy module for install it, I received the next PHP Fatal error:

Any idea? Must I write a patch and commit it?
Greetings,

David.

The class Drupal\rdf_entity\Normalizer\SparqlEntityNormalizer is still available in the repository even though the related service was deprecated in favor of the one available on sparql_entity_storage.

The access check allows the view operation but does not include the access taxonomy overview which is needed to reach the vocabulary listing page.

At the moment, the support for multiple column fields is broke (for cardinality 1 or multiple). Moreover, the form for selecting the cardinality is also broken.

The scope of this issue is:

• Fix the form for cardinality
• Fix the cardinality validation (broken as Sparql query storage doesn't not know about the %delta "column" when determining whether entities exist already with more than one value). For the moment this validation is disabled when creating the field but kicks in on the edit.
• Fix the storage loading that pieces together the field values (to allow multiple columns)
• Kernel test (using the link field)

Another issue will be created for using RDF blank nodes to model multi-value fields for cardinality higher than 1.

It seems that taxonomy vocabularies created though the UI are locked by default. The UI does not offer any option to change the value and the result is that the user cannot add any terms to the vocabulary, rendering the functionality a bit useless.

Further more, this locked mechanism is used all over the place including the rdf_taxonomy_taxonomy_vocabulary_access and rdf_taxonomy_taxonomy_term_access which are referring to the overview page.
There, the locked mechanism is checking whether the user has the view access or the vocabulary is locked. However, a locked vocabulary should not refer to the ability to view the tree. The user should not be able to add/edit/delete/reorder terms but he should be able to view them.

The SparqlEntityNormalizer class has been moved from RDF Entity to Sparql Entity Storage in #126 but now it causes a fatal error when installing RDF entity with an older version of Sparql Entity Storage which doesn't contain this class. We need to update our dependencies to require at least version 1.0-alpha4 of Sparql Entity Storage.

Example of a build that throws a fatal error during install: https://app.continuousphp.com/git-hub/ec-europa/joinup-dev/build/a299bcc2-cdfe-4690-9a47-a29f4f64b1c7/logs/5ef1dc5e-3a5e-4d4c-a668-dfafdd15de77

Class Drupal\rdf_entity\Normalizer\SparqlEntityNormalizer does not exist

Right now, the module has a limitation: It works only with entity types that are using config entities in order to define bundles.

1. Support also:
   • Entities without bundles. The user entity is such an example.
   • Entities with bundles but without bundle entity types. Example: entity_test.
2. Integrate configurable fields in the rdf_entity_mapping entity. Now they are spread in the field storage configs. We may consider to add them in the bundle rdf_entity_mapping entity so we know that all mappings are stored in a single centralized place.
3. Unify all mappings from an entity type into a single mapping config, per entity type. this is debatable. We might want a config entity for entity type (holding base fields, etc) and switch back to bundle 3rd party. EDIT: We keep the actual model rdf_entity.mapping.{entity_type}.{bundle}.yml.

RdfListBuilder::getEntityIds() checks if there is a rid in the request and includes in the query. However, when that is missing (NULL), it still includes it in the query and it fails. Simple fix.