I know it is on ADL specs, but why limit it to an URI? Second approach
could also be used to identify a subset
I understand the URI need, but I can think more than one occasion
where you have a defined termset and no URI for it
2011/2/18 Peter Gummer :
> Cati Mart?nez wrote:
>
>> ["ac0001"] = <[C
Diego Bosc? wrote:
> I know it is on ADL specs, but why limit it to an URI? Second approach
> could also be used to identify a subset
The URI approach is able to specify subsets, Diego. Here is an
example, generated by the current Archetype Editor beta release
(available from
http://www.open
If that is the valid way of defining in an URI form, it is
undocumented. the example should be put on the ADL specs.
And again not that difficult to support both kind of bindings. In my
opinion, is way more human
readable and needs the same degree of 'computer interpretation' than
the URI
2011/
Diego Bosc? wrote:
> And again not that difficult to support both kind of bindings. In my
> opinion, is way more human
> readable and needs the same degree of 'computer interpretation' than
> the URI
I would agree that the form may be more legible
to humans.
For computer interpretation, how
I think the same, Pablo
Another thing, why use a slash ('/') between terminology and version?
why don't use URI modifiers for that also?
or sub-subsets
and we have also to deal with spaces!
2011/2/21 pablo pazos :
> Hi Peter, Diego,
>
> I think the URI way to define constraint bindings can be
pablo pazos wrote:
> I think the URI way to define constraint bindings can be ambiguous
> and hide some semantics needed to understand where to find the
> terminology terms and codes.
> Please correct me if I'm wrong:
>
> One archetype can have this: ["ac0001"] = subset=DrugForm>
> And anothe
Diego Bosc? wrote:
> and we have also to deal with spaces!
>
Spaces are illegal in URIs. The correct form for the subset would be:
subset=Antiallergenic%20drugs%20(product)
- Peter
That was my point, that was a real Snomed attribute, with the spaces.
The result is even more unreadable
2011/2/21 Peter Gummer :
> Diego Bosc? wrote:
>
>> and we have also to deal with spaces!
>>
>
> Spaces are illegal in URIs. The correct form for the subset would be:
>
> ? ? ? ?subset=Antialle
I'm confused as to whether the intention here was really URI, URL or
URN?
My understanding was that the use of DV_URI for term binding in archetypes was
more in the vein of global identification of resources (more URN)
rather than actually telling the software how to get to the resource
(ala URL).
Just to clarify some more, my contention is that you cannot
look inside a arbitrary URI to pick out values without
looking at the formal 'scheme' dependent spec.
So in the case of a 'http' URI, we can read the spec and know
what the bits mean - _for the purposes of fetching data
from web servers u
and also, binding to URL seems like a bad decision for archetype
maintainability
2011/2/21 Andrew Patterson :
> Just to clarify some more, my contention is that you cannot
> look inside a arbitrary URI to pick out values without
> looking at the formal 'scheme' dependent spec.
>
> So in the case o
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110221/ea26f8b5/attachment.html>
> - we need some way to define/specify what is the canonical form of a
> URI/URN, we must agree in a terminology of names (of terminologies :D) and
> subsets.
> ? - Snomed is the same as SNOMED? or ICD10 is the same as ICD 10 or CIE 10
> (CIE = ICD in spanish)?
> - we cannot rely of one tool implem
And just as a comment, in the ADL 1.4 specs the example shows a URL.
Maybe should be better if a URN was shown
2011/2/21 pablo pazos :
> (just to clarify) I know that constraint bindings URIs are not actual
> working URIs that you can get a-la HTTP, I understand that here they are
> used as identi
Surely spaces should not be an issue here as these strings do not really
identify anything. Instead, one should be using SCTIDs as in:
terminology:Snomed?v=2002?s=135394005
Further issues include:
* the version should be specified using an ISO 8601 basic representation of
MMDD (or
___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110221/fcdb2f1b/attachment.html>
Indeed, in Australia, it would be ICD-10-AM but the version would correspond to
the particular "Edition" you're using. Hence my example URI still included the
string SNOMED so that one knows how to interpret the v=, s=, m= elements.
Clearly every standard terminology is going to have it's own
n ADL 1.5 to
allow both forms (and one day, probably we get rid of the URI form).
Does that seem reasonable?
- thomas
*
*
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.
me.ucl.ac.uk/>
Chartered IT Professional Fellow, BCS, British Computer Society
<http://www.bcs.org.uk/>
Health IT blog <http://www.wolandscat.net/>
*
*
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-techni
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110221/ddfee77c/attachment.html>
private/openehr-technical_lists.openehr.org/attachments/20110221/440d304d/attachment.html>
Thomas Beale wrote:
> What probably does make sense anyway is to relax the spec in ADL 1.5
> to allow both forms (and one day, probably we get rid of the URI
> form). Does that seem reasonable?
This would mean, then, a revision to section 8.3.1 of the AOM 1.5
spec. Currently it says that AR
I see this as an opportunity for some joint work on specification of
terminology binding, in the intersection of interests between the openEHR
community and for one: IHTSDO.
I hope the following notes are both helpful and true, corrections are most
welcome!
[Specialists language from the SNOMED
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110221/3c7b5f32/attachment.html>
ege London
<http://www.chime.ucl.ac.uk/>
Chartered IT Professional Fellow, BCS, British Computer Society
<http://www.bcs.org.uk/>
Health IT blog <http://www.wolandscat.net/>
*
*
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.o
---
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110221/5668713b/attachment.html>
*
*
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110221/e30bf26d/attachment.html>
...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110221/705a77a5/attachment.html>
28 matches
Mail list logo
