Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle inlined objects and objects with/without IDs properly #23

Open
jsheunis opened this issue Jun 18, 2024 · 0 comments
Open

Handle inlined objects and objects with/without IDs properly #23

jsheunis opened this issue Jun 18, 2024 · 0 comments

Comments

@jsheunis
Copy link
Collaborator

In a LinkML schema, classes can have a property tagged with identifier: true, which provides the ability to reference objects of those classes by its identifier (curie / uri). E.g. an Author class with a slot id set to identifier: true will allow other objects, such as Publication, to list an Author by id, provided that there is a property on Publication (e.g. authors) that has Author as the range. Tagging a slot as inlined provides additional control over whether the range class (here, Author) should be inlined or referenced by ID. If the range class does not declare an identifier then inlined is always true.

On the user interface side, this translates to the following:

  • Classes that do not have an identifier: true slot (in LinkML language) should not be editable outside of the context of the classes that "reference" them in the UI.
  • Classes that have an identifier: true slot should:
    • form the complete list of editable classes requiring no parent context for editing
    • when edited, have some way of guiding the user on how to enter the id (mainly how to select a scope from a list of prefixes, or how to enter a complete URI)
    • when saved as an entered data object, become referenceable by the id by other classes that have slots with the ID'd as range

While LinkML can be used to define a hierarchical data organisation, SHACL defines shapes to validate RDF data (e.g. a set of triples). AFAIK there is no straightforward shacl constraint or other shacl-based specification that would allow:

  • a direct mapping from LinkML's inline: true to a SHACL node property
  • identifying a specific property as an identifier for that node.

So from the perspective of SHACL-based user interface generation, we should figure out sensible ways to achieve this such that the user interface can still allow the user to see the hierarchical contexts of the data being entered, while being unaware of the hierarchical building blocks in LinkML.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant