You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Distribution schema in datalad-concepts has the concept of scoped namespaces that can be used to build URIs for objects to get unique identifiers in the given scope (e.g. an author that is unique and defined within the scope of a single "Distribution"). For more info, see:
This makes constructing metadata documents easier because a short-hand identifier can be given to any object in the document, with reference to the local scope, without having to figure out if/how to identify some object by some globally unique identifier.
From the perspective of entering metadata into a single form, with the only relevant metadata being local to said form, these local prefixes serve their intended purpose. But once the scope is broadened (e.g. when previously entered data from different users or sessions are all dumped into the same triple store, and metadata entered into a single form needs to extract from and add to such a database), the opportunity for conflicts arise because of reuse of scoped prefixes.
It seems to me that some process or convention needs to be defined by which nodes in a triple store that use such scoped prefixes should be mapped to IRIs that are unique within the broader scope of any instance of a shacl-vue application. The graph database (i.e. triple store) that is available to all forms in such an application could include any number of "imports" from metadata documents using the same scoped prefixes, i.e. conflicts should be prevented. Also, the data being entered into a form, which in principle could be using the scoped prefixed under the hood, should also be mapped in the same way before being added to the graph database.
Note: I'm not excluding the possibility that I'm misunderstanding all of this. Of course it would be a great outcome if this issue is already solved in a way that I have not yet understood. Either way, comments are appreciated.
After discussion with @mih, it seems that this should not actually be an issue. The scoped namespaces are used for contained-scope data structuring and validation, but as soon as the data is converted or exported to a format to be used externally, these curies should all be fully resolved.
The
Distribution
schema indatalad-concepts
has the concept of scoped namespaces that can be used to build URIs for objects to get unique identifiers in the given scope (e.g. an author that is unique and defined within the scope of a single "Distribution"). For more info, see:This makes constructing metadata documents easier because a short-hand identifier can be given to any object in the document, with reference to the local scope, without having to figure out if/how to identify some object by some globally unique identifier.
From the perspective of entering metadata into a single form, with the only relevant metadata being local to said form, these local prefixes serve their intended purpose. But once the scope is broadened (e.g. when previously entered data from different users or sessions are all dumped into the same triple store, and metadata entered into a single form needs to extract from and add to such a database), the opportunity for conflicts arise because of reuse of scoped prefixes.
It seems to me that some process or convention needs to be defined by which nodes in a triple store that use such scoped prefixes should be mapped to IRIs that are unique within the broader scope of any instance of a
shacl-vue
application. The graph database (i.e. triple store) that is available to all forms in such an application could include any number of "imports" from metadata documents using the same scoped prefixes, i.e. conflicts should be prevented. Also, the data being entered into a form, which in principle could be using the scoped prefixed under the hood, should also be mapped in the same way before being added to the graph database.Note: I'm not excluding the possibility that I'm misunderstanding all of this. Of course it would be a great outcome if this issue is already solved in a way that I have not yet understood. Either way, comments are appreciated.
Issues that would be influenced by this process:
identifier: true
id property correctly #25The text was updated successfully, but these errors were encountered: