Re: [Fuge-devel] Datatype ontology
Nigel Hardy
They of course do not allow the XML schema itself to do the checking or
allow XML tools to constrain the values at the user interface. Thsi is
ou dilema I think.
I am still worrying about why Boolean was specially treated in FuGE. Is
there a semantic difference between p1 and op1 in the following
(assuming that a type ontology is available). For me, the difference is
that p1 can be constrained by the schema.
<FuGE xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://fuge.sourceforge.net/fuge/1.0"
identifier="i1" name="example">
<ProtocolCollection>
<GenericProtocol identifier="myProtocol">
<GenericParameter identifier="p1">
<BooleanValue value="false"/>
</GenericParameter>
<GenericParameter identifier="p2">
<AtomicValue value="false">
<_dataType OntologyTerm_ref="BooleanType_term"/>
</AtomicValue>
</GenericParameter>
</GenericProtocol>
</ProtocolCollection>
</FuGE>
Nigel
Miller, Michael D (Rosetta)
> I am still worrying about why Boolean was specially treated
> in FuGE.
i don't know if you've ever participated in a core group of people
developing a standard but it involves meeting every few months in some
sweaty small room with everyone cramped in. everyone has their own
ideas but the idea is to come to some sort of consensus. there are
also a lot of areas to cover.
so it isn't a perfect process but the good that comes out of it almost
always out weighs the bad, which for FuGE seems to be the case.
as i recall, there was general agreement on the Measurement package but
how to represent the concrete measurements in the model went back and
forth between a few ideas when i think andy proposed what basically
became the final version. often it is a matter of everyone finally
being happy enough or too fatigued to care anymore.
you have a good point about calling out BooleanValue, it is odd to call
out one particular datatype, but i think the reasoning was that it was a
very common case and would cut down on the clutter in the XML.
i think i would have liked to have seen an Enumerated measurement called
out, that's becoming very common these days. i also think your
suggestion on restricting the datatype/unit was a great one, to do that
would require marking the dataType and unit associations with the
<<AbstractAssociation>> stereotype and then probably having a
GenericMeasurement between the current subclasses of Measurement and
Measurement to define concrete associations. then FuGE extensions could
subclass from Measurement and create subclasses of the associations with
the desired restrictions.
cheers,
michael
Michael Miller
Lead Software Developer
Rosetta Biosoftware Business Unit
www.rosettabio.com
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Fuge-devel mailing list
Fuge-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fuge-devel
Nigel Hardy
> hi nigel,
>
>
>> I am still worrying about why Boolean was specially treated
>> in FuGE.
>>
>
> i don't know if you've ever participated in a core group of people
> developing a standard but it involves meeting every few months in some
> sweaty small room with everyone cramped in. everyone has their own
> ideas but the idea is to come to some sort of consensus. there are
> also a lot of areas to cover.
>
answer :-) Thanks. It gives me some confidence on how to build forward,
knowing that I am not missing something in my basic understanding.
Nigel