On Tue, Jan 31, 2012 at 14:42, Thomas Beale < thomas.beale at oceaninformatics.com> wrote:
> Erik, > which file do you mean here? Where is this alias? Oh, never mind, it was just a sidetrack, focus on other things if you don't get it. Let's not spend more email electrons, CPU cycles and brainpower on this part of the thread. What I meant was that a serialized archetype- or template-file that uses a lot of similarly prefixed URIs could use internal aliases (defined in that specific archetype- or template-file) for long URI prefixes. This is done by many other RDF and XML serialization approaches to increase readability. But let's not do anything like that for ADL now. Maybe those of us that are interested in e.g. XML and YAML (that already have built-in prefix/namespace mechanisms) could look at this later. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 > On 31/01/2012 13:12, Erik Sundvall wrote: > > Hi! > > On Tue, Jan 31, 2012 at 13:44, Thomas Beale < > thomas.beale at oceaninformatics.com> wrote: > >> If going for an RDF-like URI based approach for "program directives" >> or "implementation_directives" then those serialization formats that aim >> for human readability (e.g. ADL and YAML) may want to use some kind of >> URI-prefixing-mechanism to make the directives shorter and more readable. >> (Similar approaches are used in XML (namespaces) and many >> RDF serialization formats.) >> >> I would opt for "implementation_directives", less ambiguous. >> > > In that part of the mail I was thinking of shortening serialisations of > things like... > > ["http://schema.openehr.org/GUI-v0_1#view";] = <" > http://schema.openehr.org/GUI-v0_1#pass_through";> > > ...to something like... > > ["gui:view <http://schema.openehr.org/GUI-v0_1#view>"] = <"gui: > pass_through <http://schema.openehr.org/GUI-v0_1#pass_through>"> > > ...by somewhere in the file defining > > gui: > > ...to mean... > > > http://schema.openehr.org/GUI-v0_1#<http://schema.openehr.org/GUI-v0_1#pass_through> > > // Erik > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120201/7b8b8976/attachment.html>
