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

How to map record IRIs using scoped namespaces to unique IRIs in a broader scoped database #33

Closed
jsheunis opened this issue Jun 26, 2024 · 2 comments

Comments

@jsheunis
Copy link
Collaborator

jsheunis commented Jun 26, 2024

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.

Issues that would be influenced by this process:

@jsheunis
Copy link
Collaborator Author

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.

@jsheunis
Copy link
Collaborator Author

jsheunis commented Sep 9, 2024

Closing

@jsheunis jsheunis closed this as completed Sep 9, 2024
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