RE: CKM for training purposes
+1 pls Cheers, -koray From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Heather Leslie Sent: Monday, 20 July 2015 8:14 p.m. To: For openEHR implementation discussions; For openEHR implementation discussions; For openEHR technical discussions Subject: CKM for training purposes Hi everyone, I'm seeking expressions of interest by groups who are interested in participating in an instance of CKM for the purposes of training in openEHR governance. It is intended to have the first iteration of the training CKM up and running in time for Medinfo, which is only 4 weeks away. Rather ambitious perhaps, and this will only be possible if it is viable from the point of view of demand from the openEHR community and some commitment to contribute a modest amount towards the running/maintenance/adaptation costs for education purposes. Over time we could potentially add functionality that will allow lecturers/teachers to manage a subdomain per class, which could be cleared and reset at the end of each course to provide a clean starting point for the next group etc. I have already had some great ideas suggested that would enable lecturers to run multiple courses in parallel and identify participation from individual class members etc. Please email me directly on heather.les...@oceaninformatics.commailto:heather.les...@oceaninformatics.com and we can start more detailed discussions with all interested parties and determine if this idea is of interest and potentially viable. Kind regards Heather Dr Heather Leslie MBBS FRACGP FACHI Consulting Lead, Ocean Informaticshttp://www.oceaninformatics.com/ Clinical Programme Lead, openEHR Foundationhttp://www.openehr.org/ Phone - +61 418 966 670 Skype - heatherleslie Twitter - @omowizard ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
RE: Term set for DV_PARSABLE.formalism
I think we can put the formalisms we know in the terminology, but being flexible to allow local formalisms, like using local for the terminology_id. If we don't do that, we'll need to maintain the terminology for every new formalism. Not sure about having two fields, it seems the role of both is the same. We can do that with parameters or suffixes on MIME types (the structure allows that): https://en.wikipedia.org/wiki/Internet_media_type With CODE_PHRASE we can cover both cases, defined and non-defined MIME types. If the MIME type is String, we lose control over the values, I'm considering trying to process something I receive and not understanding that String. With terminology = local, I know that I may not have the code (if local is another system), but for a MIME type from IANA I will have it. Also this allow us to define our own openEHR types without the need of registering those at IANA, like ADL or OPT (e.g. text/opt+xml). -- Kind regards, Eng. Pablo Pazos Gutiérrez http://cabolabs.com Subject: Re: Term set for DV_PARSABLE.formalism To: openehr-technical@lists.openehr.org From: thomas.be...@oceaninformatics.com Date: Tue, 28 Jul 2015 19:38:40 +0100 On 28/07/2015 18:49, pablo pazos wrote: If that's the case, we lose the coding system / terminology of the mime types that are defined. It would be better to make DV_PARSABLE.formalism of type CODE_PHRASE instead of String and use local for the terminology_id of those formalisms that doesn't have a mime type. well actually we could do that and put all those other formalisms into the openEHR terminology. The original idea was to allow (encourage) MIME types as strings, and then outside of MIME, any other formats just as their own short string, e.g. 'mp5' (imagine it exists), or 'adl'. There are a lot of formats that are essentially text/plain, but the format is actually parseable, e.g. glif3, most programming languages and so on. So 'text/plain' isn't that useful a thing to know. I wonder if we have to give in and have two fields, one that is a MIME type field (the current one) and a second field that has a term defining the semantic format, mostly applicable when the MIME type field is text/plain, text/xml and other text types. - thomas ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
RE: Term set for DV_PARSABLE.formalism
If that's the case, we lose the coding system / terminology of the mime types that are defined. It would be better to make DV_PARSABLE.formalism of type CODE_PHRASE instead of String and use local for the terminology_id of those formalisms that doesn't have a mime type. thoughtS? -- Kind regards, Eng. Pablo Pazos Gutiérrez http://cabolabs.com Date: Mon, 27 Jul 2015 08:23:49 +0200 Subject: Re: Term set for DV_PARSABLE.formalism From: yamp...@gmail.com To: openehr-technical@lists.openehr.org CC: openehr-implement...@lists.openehr.org Probably was left this way to deal with the ones that don't have an official mime, like adl El 27/7/2015 7:11, pablo pazos pazospa...@hotmail.com escribió: Reading the specs I realize that there isn't a term set for DV_PARSABLE.formalism and it is a free text attribute. Since stuff like XML, JSON, CSV, etc. are in fact modeled by DV_PARSABLE, and those have a MIME type associated (text/xml, application/json, text/csv, ...), shouldn't we define a term set for that attribute like we have for DV_MULTIMEDIA.media_type? (of course this attribute is CODE_PHRASE and not String like formalism). -- Kind regards, Eng. Pablo Pazos Gutiérrez http://cabolabs.com ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: Term set for DV_PARSABLE.formalism
On 28/07/2015 18:49, pablo pazos wrote: If that's the case, we lose the coding system / terminology of the mime types that are defined. It would be better to make DV_PARSABLE.formalism of type CODE_PHRASE instead of String and use local for the terminology_id of those formalisms that doesn't have a mime type. well actually we could do that and put all those other formalisms into the openEHR terminology. The original idea was to allow (encourage) MIME types as strings, and then outside of MIME, any other formats just as their own short string, e.g. 'mp5' (imagine it exists), or 'adl'. There are a lot of formats that are essentially text/plain, but the format is actually parseable, e.g. glif3, most programming languages and so on. So 'text/plain' isn't that useful a thing to know. I wonder if we have to give in and have two fields, one that is a MIME type field (the current one) and a second field that has a term defining the semantic format, mostly applicable when the MIME type field is text/plain, text/xml and other text types. - thomas ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
