Using labels instead of the local IDs for naming API resources and PHP classes

[Angatar]

Description

The schema-generator currently defines the API resources and PHP classes names using the designated vocabulary/ontology classes' local IDs (=ID of the URI fragment identifier). If we want to use another name for the corresponding Entities/classes we have to set it manually in the config file.
This behavior is quite OK when using small config or if the vocabulary/ontology is using comprehensive IDs like with Schema.org, but it is not OK with any extensive use of vocabulary/ontology like OBO ontologies or wikidata that are using numerical IDs.
https://obofoundry.org/
https://www.wikidata.org/

It would be great to have a new configuration option allowing to name Entities/PHP classes from the corresponding vocabularies/ontologies labels instead of using the ID part of their URI fragment Identifier.

Example

As an example, the run of schema-generator with the following small graph

vocabularies:
- https://ontobee.org/ontology/rdf/NCIT?iri=http://purl.obolibrary.org/obo/NCIT_C94196
allTypes: true # Generate all types by default for vocabularies
nameAllFromLabels: true # Make use of the label information when possible to define all entities names
namingConvention: snake case # Selecting a naming convention for naming PHP classes and API resources by using the labels
language: en # Selecting the language to use with the labels in case different languages are available

Should lead to the creation of intelligible PHP files names.

Blocking_antibody.php
Virus_neutralizing_antibody.php

In this example the list of exposed API resources should only contain Virus_neutralizing_antibody as it is a child of Blocking_antibody in the provided graph

** Advantages **

This feature would widely enable api-platform with the generation of intelligible APIs from all vocabularies/ontologies, even the ones using numerical IDs, including the structured data from Wikidata and OBO ontologies.

A basic use case would be to make it possible to simply generate an API with the API platform schema generator directly from a project ontology that contains Wikidata and/or OBO resources as entities classes.