*Corrected first sentence*
/Mattias
2007/1/8, Mattias Forss <mattias.forss at gmail.com>:
>
> Hi Jose,
>
> I don't think the meaning of the node will change, but it depends on how
> you define it. If we think of the reference node (use_node) as a shortcut to
> an entry form. Also think of it as if that shortcut decided how many times
> the same entry form would show up. If we override the occurrences we don't
> change the meaning of the entry form.
>
> However, if the original meaning of having for example 2 occurrences of a
> node we're referencing is to enter observations about two different sites
> (say internal and external) and if we are allowed to override those
> occurrences, then the original purpose of the node is not fulfilled because
> it allows entry to be made less or more times.
>
> This was probably not a full answer to your question.
>
> Regards,
>
> Mattias
>
>
> 2007/1/8, Jose Alberto Maldonado <jamaldo at upvnet.upv.es>:
> >
> > Hi all,
> >
> > we have a doubt regarding the possibility of overriding occurrences of
> > referenced node. The main concern has to do with the fact that a occurrence
> > constraint is "part" of the semantics of the node being constrained. If it
> > is true, when overriding the occurrences of referenced nodes, do we change
> > the meaning of the original node and therefore the description (and even
> > terminology binding) might become erroneous?.
> >
> > best regards
> >
> >
> >
> >
> > Mattias Forss escribi?:
> >
> >
> >
> > 2007/1/8, Thomas Beale <Thomas.Beale at oceaninformatics.biz>:
> > >
> > >
> > > >
> > > > Koray Atalag wrote:
> > > >> QUESTION-1: What is the correct approach for above problem?
> > > >>
> > > as Sam has said your understanding is correct and the archetype is in
> > > error.
> > > >> QUESTION-2: Assume in some other place in the archetype you
> > > reference
> > > >> the ELEMENT node with occurences {0..8} by use_node. And in this
> > > >> particular place you do not want to have up to 8 instances and but
> > > also
> > > >> you want it to be mandatory (i.e. 1..) or even want {3..5}. What is
> > > the
> > > >> solution? (other than writing the whole thing once again)
> > > >>
> > > the current semantics are that the occurrences of the referenced node
> > > are what takes effect. However, I agree that a preferable approach
> > > would
> > > be if the occurrences could be overridden at the origin point of the
> > > use_node reference. This would not be incompatible with the current
> > > semantics, and would probably be a useful change. What do others
> > > think?
> > > [Particularly the Archetype tool authors]?
> >
> >
> > Hi Thomas,
> >
> > I think it would be a good idea to let the users of the archetype
> > editors override occurrences of referenced nodes.
> >
> > Regards,
> >
> > Mattias
> >
> >
> > Note that in the AOM, an
> > > ARCHETYPE_INTERNAL_REF inherits occurrences from C_OBJECT, so in
> > > theory
> > > our archetype parsers should handle them, but I have just looked at
> > > mine, and it doesn't...Rong, how about the Java parser? (So much for
> > > having complete test archetype coverage;-)
> > > >> QUESTION-3: Related with second question, I also need to disallow
> > > usage
> > > >> of some values when referencing by use_node entries. This I believe
> > > is
> > > >> not an uncommon requirement in clinical medicine.For me I have an
> > > >> element with a long list of values of sites of an organ
> > > (Esophagus,
> > > >> stomach, colon and so on) and in many places of an observation
> > > these
> > > >> sites repeat without change so I can reference original. But in
> > > some
> > > >> cases selection of certain site(s) is not logical and should better
> > > be
> > > >> restricted or selection of only one site makes sense. What is the
> > > solution?
> > > >>
> > > I actually think there are various solutions here...
> > > * the most obvious would be that at the point of reference, you create
> > > a
> > > CLUSTER node, and then individually reference the subset of paths of
> > > items from the target CLUSTER that you want, but not others.
> > > * another one would be to make a number of ITEM_TREE or ITEM_LIST
> > > archetype of the relevant piece of content as separate archetypes, and
> > >
> > > use slots to include particular subsets.
> > > * a third possibility is to use invariants to prevent certain paths
> > > from
> > > existing that would otherwise be allowed by the main part of the
> > > definition of the archetype.
> > >
> > > - thomas beale
> > >
> > >
> > > _______________________________________________
> > > openEHR-technical mailing list
> > > openEHR-technical at openehr.org
> > > http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
> > >
> >
> > ------------------------------
> >
> > _______________________________________________
> > openEHR-technical mailing listopenEHR-technical at
> > openehr.orghttp://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
> >
> >
> > --
> > Jose A. Maldonado. Ph. D.
> > Bioengineering, Electronic and Telemedicine Group
> > Escuela Universitaria de Informatica
> > Technical University of Valencia
> > Camino Vera s/n
> > 46022 VALENCIA (Spain)
> >
> > Tel. + 34 96 387 70 07 ext: 75277
> >
> > e-mail: jamaldo at upvnet.upv.eshttp://bet.upv.es
> >
> >
> >
> >
> > _______________________________________________
> > openEHR-technical mailing list
> > openEHR-technical at openehr.org
> > http://www.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/20070108/9d08b56e/attachment.html>
-------------- next part --------------
_______________________________________________
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
