A compatible alternative might be to use metadata to annotate
components, variables, imports, etc. with human readable names (see
section 4.7 in the metadata specification, for example). Model authors
could then give descriptive names to whatever they wish possibly making
it easier to locate specific variables in a GUI. Might be nicer than
rendering long URI's.
Of course, getting the user navigation of the hierarchy of such names to
be sensible and intuitive would still be essentially the same problem as
below. But at least the model author could give clues to distinguish the
high level imported components.
Andre.
Andrew Miller wrote:
> - - wrote:
>> Hi,
>>
>> Thanks for the quick reply,
>>
>> I am using CellML 1.1PCEnv
>>
>> To put the (...And when I have imported the same component twice,)
>> question into context:
>>
>> I have created an import file consisting of 2 components (a and b).
>> I have created another import file consisting of 2 components (a and c).
>>
>> I have imported both of the IMPORT files into 1 single file
>> ( But in the 2nd file, I have renamed 'a' as 'a2'using
>> component_ref:a and name_ref:a2)
>>
>> Everything works fine, but when I am selecting properties to be shown
>> on the graph, My options (for components) are : a
>> a
>> c.
>>
>> My question is
>> : Is there anyway to name them such that my
>> components options when drawing a graph are : a
>>a2
>>
>> c?
> Hi Habib,
>
> The naming of components on the graph control is something that I am
> interested in improving. I am not sure that it would be as simple as you
> suggest - after all, you can import a component to multiple levels, and
> there can be components pulled in due to the grouping facilities in
> CellML which do not have a name supplied in the importing model.
>
> One option for future improvements which I suggested when someone else
> came to me with the same issue was to have multiple levels of context
> menu mirroring the import structure in the graph control. So for
> example, instead of the current two-level Component => Variable menu, it
> could be:
>
> Component => Variable (all names based on their names in the top level
> model, even if they are imported).
> Import URL => Component (named as in the imported model) => Variable
> Import URL => Import URL => Component
> and so on. Note that the same imported component would be listed more
> than once, but under potentially different names.
>
> The only problem with the above is that the same model can be imported
> more than once, and so identifying components which are implicitly
> imported more than once due to grouping would be problematic.
>
> The other option would be to put components under other components
> following the encapsulation hierarchy in CellML, in which case we
> probably could use the name from the highest level the component is
> imported to.
>
> Thanks for your feedback on PCEnv.
>
> Best regards,
> Andrew
>
>> Thanks again.
>>
>>
>>> From: Andrew Miller <[EMAIL PROTECTED]>
>>> To: CellML Discussion List
>>> CC: [EMAIL PROTECTED]
>>> Subject: Re: [cellml-discussion] CellML technical question.
>>> Date: Wed, 01 Aug 2007 09:30:26 +1200
>>>
>>> - - wrote:
Hi,
I would like to know why multiple files appear in the right side of
window when I open just ONE import file ? Can I do anything to
change this ?
>>> Hi Habib,
>>>
>>> Just so we have some context to put your question in, would you be
>>> able to describe what software package these results occur in? As far
>>> as I am aware, PCEnv is the only visual editing environment to
>>> support imports in CellML, but I am having trouble relating what part
>>> of PCEnv you would be referring to, as PCEnv puts graphs on the right
>>> hand side by default, which are completely user-defined.
>>>
And when I have imported the same component twice, and I change the
reference name for one of the components, Shouldnt the component
have that new name (so i can differentiate when using graphs and
such) ?
>>> Imported components generally need two or more names (depending on
>>> how many times they are imported, because an imported component can
>>> be further imported), and which one is used does of course depend on
>>> what context they are referred to in. Unfortunately, it is not always
>>> as simple as taking the 'top most' name, because importing one
>>> component will often bring in others with it due to the encapsulation
>>> mechanisms in CellML.
>>>
>>> Perhaps if you could describe specifically where a component name is
>>> appearing on the UI that you think is not the best one to be using,
>>> we can discuss how this c
