The current naming conventions for URIs seem a little bit random, and make it difficult for humans to work with them. There are also some errors in terms of what is declared as part of the global desm namespace or using the global desm website URI.
This relates mostly to the JSON-LD and TTL mapping exports, but will also affect config exports in those formats.
This only affects the URIs for entities created during a mapping, it explicitly does not relate to the URIs for DESM mapping properties and classes, they should begin http://desmsolutions.org/ns/
Nothing uploaded with an RDF id should be given a new one (e.g. mapping predicate skos:Concepts)—though be aware that we declare local "copies" of properties which are subProperties of those in the schema (this is so that we can say things about our local copies that are only locally true, and so that we can handle non-RDF terms).
Here is a list of types of entity (from the Domain Model) that are created during the mapping and what they could redirect to:
DESM Class
Tool URI
MappingConfiguration
/mappings-list?cp=n [1]
AbstractClassMapping
/mappings-list?cp=n&abstractClass=ClassName
TermMapping
/mappings-list?cp=n&abstractClass=ClassName#id
Schema
nothing [1]
DSO
leave for now [2]
Agent
/dashboard/agents#id [3]
Property
/mappings-list?cp=n#id [4]
Notes:
We have an issue (#578) that there should be something like a "home page" for each mapping project, that could live at /mappings-list?cp=n and could include or link to information about the schemas mapped.
DSO will be affected by the rewrite of how we handle agent roles and affiliations.
Login would be require to see this. I don't think it is in the public downloads anyway, just the full config download.
I am not sure what to serve for local property URIs created during the mapping exercise (e.g. for XML or CSV schemas)
The current naming conventions for URIs seem a little bit random, and make it difficult for humans to work with them. There are also some errors in terms of what is declared as part of the global desm namespace or using the global desm website URI.
This relates mostly to the JSON-LD and TTL mapping exports, but will also affect config exports in those formats.
This only affects the URIs for entities created during a mapping, it explicitly does not relate to the URIs for DESM mapping properties and classes, they should begin http://desmsolutions.org/ns/
Nothing should begin with http://desmsolutions.org/ns/ that is not a term defined in the desm namespace.
Nothing uploaded with an RDF id should be given a new one (e.g. mapping predicate skos:Concepts)—though be aware that we declare local "copies" of properties which are subProperties of those in the schema (this is so that we can say things about our local copies that are only locally true, and so that we can handle non-RDF terms).
URIs for entities created during a mapping should begin with the base URI for of the tool being used for the mapping, e.g. https://gopher.desm.staging.c66.me/ https://tool.desmsolutions.org/ or https://desm.credentialengine.org/ etc.
The URIs should also reflect the class of thing they refer to. So if soemthing has type desm:TermMapping it would have a URI starting https://base.for.tool/TermMapping/ and if something has type desm:AbstractClassMapping it would have a URI starting https://base.for.tool/AbstractClassMapping/ and so on.
These should resolve to something related to what they represent. For example rather than https://desm.credentialengine.org/TermMapping/6731 we might want a term mapping id to be https://desm.credentialengine.org/TermMapping/6/Assertion#6731 that redirects to https://desm.credentialengine.org/mappings-list?cp=6&abstractClass=Assertion
Here is a list of types of entity (from the Domain Model) that are created during the mapping and what they could redirect to:
Notes: