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

WIP: Ontology Namespaces #3

Open
MichaelHirn opened this issue Apr 4, 2019 · 0 comments
Open

WIP: Ontology Namespaces #3

MichaelHirn opened this issue Apr 4, 2019 · 0 comments
Labels
question Further information is requested

Comments

@MichaelHirn
Copy link
Contributor

Summarizing the discussion @hobofan and I have had regarding namespaces in ontologies.

In RDF we have something like rdf:string and schema:string, where different ontologies - rdf and schema in this example - can have the same ontological entity (schema) name - in this case string. Important to note is, that although they share the same entity name they may differ semantically (and rdf:string can mean something else than a schema:string).

The namespace allows developers and users of these ontologies to use multiple ontologies in their application, without fearing any name-clashes, esentially giving guarantees of resolvability via a human-understandable ID and not only via the CID.

Presently, rlay does not support any namespace capabilities and it is up to the application developer/ontology user to ensure that different ontologies (or their own ontology) does not clash. The way this can be ensured right now, is by taking the namespace into the name of the ontological entity, e.g. StringRDF or StringSchema.

However, this makes sharing ontologies difficult, because of the implied naming convention. Also, this does not make nameclashes impossible either.

Proposed solutions are referring to npm, Annotations, and more or less rlay custom annotations to introduce namespaces. Namespaces are closely related to sharing and importing ontology packages, so it might make sense to combine multiple strategies to achieve this.

However, no clear winner emerged in the last discussion, which is why we created this issue, to collect thoughts and allow to refresh our memories on the subject.

@MichaelHirn MichaelHirn added the question Further information is requested label Apr 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant