Closed HeinrichPet closed 2 years ago
Good point! Following dcat-3, we could reuse dct:title
and dct:description
to the Catalogue's SHACL shapes.
I'll take a look into it. Should be easy to add.
I would appreciate if this non breaking change would be realized before 5.0.0
As long as we do not introduce these as mandatory fields, this should be a non-breaking change and therefore to be released in prior to 5.0.0. Adding the respective label.
Maybe you should think about adding title and description as optional attributes for various types, not only catalogs, in the long term - if this is not already the case. This somehow could allow an easier identification of objects. For example, the DSC defines all objects as Entity
with a subclass called NamedEntity
, containing the attributes title
and description
, that all model classes can inherit from.
For example: Representation, Catalogs, Artifacts, .....
@HeinrichPet Could you please clarify the scope of this? Would you like to (1) improve the ontology documentation or (2) be able to add title + description to instantiated catalogues during runtime? Thank you in advance.
(2) Is easy to add (see @HaydarAk 's comment above), while (1) requires a major edit.
@JohannesLipp We want to enable the user to name or identify objects in the IDS information model. Currently this is only possible via the very cryptic IDs, which is not very intuitive. So, in order to provide a good user experience with the IDS, as many objects as possible need an entity with the attributes title and description. This makes it possible to describe the purpose of an object and make it human readable and referenceable.
The closest match is probably your point 2, although the title and description are more likely to be added at instantiation itself.
@JohannesLipp Are there any updates on this one? Seems to be a valid argument to introduce these changes instead of using workarounds in the underlying data models to overcome this issue.
@JohannesLipp Are there any updates on this one? Seems to be a valid argument to introduce these changes instead of using workarounds in the underlying data models to overcome this issue.
Yes we will tackle this soon, as it is of practical relevance. We are still in the state of transferring Haydar's issues (like this one) to other colleagues, who will solve them. We will keep you tuned.
There exists an abstract class ids:Described that has an dct:title and dct:description in its SHACL-Rules 1. Currently, only a limited number of IDS-Classes inherit from this class, such as ids:Resource and ids:ManagedEntity. We could make more IDS-Classes subclasses of ids:Described. That would be non-breaking, as it contains no mandatory fields. @HeinrichPet Which classes should be included?
As already mentioned:
For example: Representation, Catalogs, Artifacts, .....
Routes, Subroutes, ...
Maybe you just go through the information model and imagine what a user might want to title to make it easier to find again.
@PHochmann then please do that change for these five classes: Representation
, Catalogs
, Artifacts
, Routes
, Subroutes
.
In the latest DSC UI version we now use IDS catalogs in which multiple resources can be stored. This is very helpful for the provider to sort his resources. Unfortunately, the catalogs cannot be given titles in the information model, so when a consumer queries the catalogs, he does not know what he will find under which catalog.
Accordingly, we would wish that a catalog also gets a title and a description.
Best regards, Heinrich