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 peter.gummer at oceaninformatics.com:
Cati
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
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, ORGANIZATIONX::DrugFormSubset is way more human
readable and needs the same degree of 'computer
Diego Bosc? wrote:
And again not that difficult to support both kind of bindings. In my
opinion, ORGANIZATIONX::DrugFormSubset is way more human
readable and needs the same degree of 'computer interpretation' than
the URI terminology:...
I would agree that the TERMINOLOGY::subset form
Diego Bosc? wrote:
and we have also to deal with spaces!
terminology:Snomed?v=2002?s=Antiallergenic drugs (product)
Spaces are illegal in URIs. The correct form for the subset would be:
subset=Antiallergenic%20drugs%20(product)
- Peter
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
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
and also, binding to URL seems like a bad decision for archetype
maintainability
2011/2/21 Andrew Patterson andrewpatto at gmail.com:
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
://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/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
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 pazospablo at hotmail.com:
(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
-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
/attachments/20110221/ae6f6d1a/attachment.html
-- next part --
A non-text attachment was scrubbed...
Name: ocean_full_small.jpg
Type: image/jpeg
Size: 5828 bytes
Desc: not available
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments
/mailman/private/openehr-technical_lists.openehr.org/attachments/20110221/ddfee77c/attachment.html
-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
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
://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110221/3c7b5f32/attachment.html
://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-technical_lists.openehr.org/attachments/20110221/6de6fdf2/attachment.html
-- next part
:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110221/5668713b/attachment.html
/private/openehr-technical_lists.openehr.org/attachments/20110221/705a77a5/attachment.html
22 matches
Mail list logo
