Re: [SED-ML-discuss] Future of SED-ML

[Andrew M. <ak....@au...>]

On 20/01/12 08:35, Lucian Smith wrote:
> I also agree.  Another way of looking at this is that it's like the
> 'Methods' section of a paper.  And the problem with Methods sections is
> that they're tedious and people don't like to do them properly, so you
> end up with bits that just say "We followed the Haversham protocol here"
> and if you look up Haversham they claim to follow the Hawley-Smoot
> protocol from 1951, and while the general approach is the same, the
> specifics of what actually gets performed in the lab have changed over the
> years.
>
> So while it's fine to annotate a simulation protocol 'Haversham, 1992', it
> is best if you actually have something that can really be followed down to
> the last detail.  In that way, you allow people to see the nuts and bolts
> of what you did slightly differently to Haversham, and they can see for
> themselves if it's merely for efficiency, or if it makes a material
> difference in the simulation.
>
> So, yes.  SED-ML should ideally end up roughly equivalent to a
> domain-specific programming language.  I believe this will make it more
> procedural and less declarative (unlike the models they manipulate), but
> that's simply because of the nature of the problem it sets out to solve.

I don't disagree that something like this should exist - it would be 
great if there was a high-level language (like SED-ML is now) that could 
refer to a library of descriptions of general simulation experiment 
types. That way, high-level descriptions can be created, and if it 
doesn't do something that is required, you can code up the imperative 
description of a new type of simulation experiment, add it to the 
library, and then refer to it. I would prefer that SED-ML was the 
high-level language and we called the lower level one something else, 
but either way, we need both.

I don't think anyone has made a convincing argument for reinventing the 
wheel to create this domain-specific programming language. Frank said:

   "Again, the key point is to be able to *exchange* the description so
    it can be reproduced and validated using different software tools.
    Essentially to be able to apply the scientific method to simulation
    experiments. You don't get that with a general purpose programming
    language".

You absolutely can exchange imperative code - we could embed fragments 
of Python in a file, or perhaps use something like Haskell that runs in 
a custom monad and so doesn't have access to IO facilities; there are 
already different implementations of both Python and Haskell, and they 
could certainly be used from different software tools. Java applets are 
a good example of how imperative code descriptions of applets are 
exchanged between software implementations - the same applet can be run 
in different browsers, using different Java implementations.

Of course, the line between the software tool and the imperative code 
being exchanged can get a bit blurred if a significant amount of the 
logic for a software tool comes from a database, but this is inevitable 
and applies just as much if we reinvent an expressive imperative language.

Best wishes,
Andrew

>
> -Lucian
>
> * Jonathan Cooper<jon...@cs...>  [2012-01-19 19:18] writes:
>> Hi all,
>>
>> Not really anything to add here, but I agree 100% with Frank and think
>> he expressed it very well!
>>
>> Best wishes,
>> Jonathan
>>
>> On 19/01/2012 17:34, Frank T. Bergmann wrote:
>>> Hello Andrew,
>>>
>>> I modified the subject for this one, as I believe it is a vital topic to be discussed and it certainly is independent of the nested proposal.
>>>
>>>> I think that if a proposal like this was included in SED-ML, it would
>>>> fundamentally change what SED-ML is, and make SED-ML into something
>>>> which has no distinct utility over and beyond a general purpose
>>>> programming language.
>>>>
>>> Yes it has, SED-MLs aim is to describe simulation experiments independently from a model definition language and independent from the original software application that gave rise to it. This is of great utility and IMO quite distinct from anything we have.
>>>
>>> If however we don't have a a general construct like the one outlined in the nested proposal, we end up with a small selection of highly specialized simulation classes that will fit a small number of experiments. Even if we allow those simulation experiments to expand over time, it will take a long time to be adopted by software. Essentially, for me this would make SED-ML no longer as interesting.
>>>
>>> Remember we have all facilities to annotate the protocol of how the simulation result was obtained in the first place. You are free to use miriam annotations and any ontology you'd like.
>>>
>>>>    From a description of a simulation experiment, it is possible to
>>>> replicate the experiment, but it is also possible to do other types of
>>>> analysis - for example, inferring the intent of the simulation
>>>> experiment and perhaps performing automated reasoning from the result.
>>>>
>>> And why could you not do this with a well annotated nested simulation? What would prevent you to annotate it with the same terms that you would use for a highly specialized parameterScan simulation class?
>>>
>>>> Someone wanting to code a procedure, without necessarily describing
>>>> higher level semantic information about the procedure, would be better
>>>> off using an existing general purpose imperative programming language -
>>>> they don't need SED-ML for that.
>>> Again, the key point is to be able to *exchange* the description so it can be reproduced and validated using different software tools. Essentially to be able to apply the scientific method to simulation experiments. You don't get that with a general purpose programming language.
>>>
>>>> However, SED-ML is far more useful if it is targeted at describing
>>>> simulation experiments. This means that it does need to incorporate
>>>> facilities for a large number of different types of simulation
>>>> experiments. This is a significant amount of work, but it is the
>>>> meaningful approach consistent with the current SED-ML. It means we need
>>>> to have very streamlined processes for adding new types of simulation
>>>> experiments to the language, and to make the language more extensible.
>>> This in my opinion would make SED-ML extremely unattractive to adoption, as it would always be a moving target with each version supporting a different number of simulation classes. As such it would impose a high maintenance risk to any software team. This will imply that descriptions encoded in one tool are very likely not to run in another, as they are extremely likely to support a different number of simulation classes.
>>>
>>> To close: with the nested simulation experiment we get the best of both worlds. We have a description of all the required steps to reproduce the results AND we have the capabilities to annotate it to allow reasoning over it.
>>>
>>> Frank
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Keep Your Developer Skills Current with LearnDevNow!
>>> The most comprehensive online learning library for Microsoft developers
>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>> http://p.sf.net/sfu/learndevnow-d2d
>>> _______________________________________________
>>> SED-ML-discuss mailing list
>>> SED...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>
>> ------------------------------------------------------------------------------
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> _______________________________________________
>> SED-ML-discuss mailing list
>> SED...@li...
>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss