Broaden LOCATABLE_REF.as_uri() to allow URIs referring to any health data

Description

LOCATABLE_REF.as_uri() should be relaxed to accommodate non-ehr uri schema (for DEMOGRAPHIC PARTY.reverse_relationship)

Activity

Show:
Sebastian Iancu
January 10, 2019, 10:09 AM

perhaps we should already create a ticket for the future, so that we don't forget we need to elaborate on these uri-scheme

Pablo Pazos
January 11, 2019, 11:21 PM

The meaning has: "id.value" what does that mean?

Can we add some examples to the meaning of as_uri()?

REF: https://specifications.openehr.org/releases/BASE/latest/base_types.html#_locatable_ref_class

Thomas Beale
January 12, 2019, 12:13 AM

Ideally I would do that, but I think we need to do this in a larger CR that addresses the whole path / URI question. THe main intent here was to remove the limitation that URIs generated by this function would only be in the 'ehr' scheme space.

Pablo Pazos
January 12, 2019, 12:18 AM

Maybe we should remove the parts altogether if the idea was to just relax the URL, because it can be confusing without a clear definition of each part, like current "id.value" and having no examples makes it more difficult to understand.

If the ehr scheme is the only required part, we can remove the other parts and add a text description that the url can be formed of any components or parts needed by the implementation. And note that will be more defined in the future.

What do you think?

Thomas Beale
January 12, 2019, 12:43 PM

I also agree with you logically, but in terms of spec maintenance, this (weak) definition was already there (https://specifications.openehr.org/releases/RM/Release-1.0.3/support.html#_locatable_ref_class), so I think we either leave it as is, with just the scheme name fix of this CR, or else (maybe better) we push this CR up to another release, and make it solve the URI question comprehensively.

I'm fine with either way.

Reporter

Sebastian Iancu

Raised By

Sebastian Iancu

Components

Affects versions

Configure