Skip to content

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

Open
@Angatar

Description

@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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions