[Auscope-geosciml] MOLES schemas [SEC=UNCLASSIFIED]

Oliver.Raymond at ga.gov.au Oliver.Raymond at ga.gov.au
Wed Mar 10 21:59:02 EST 2010


Hi Bruce

See comments inline in red.

Today I had a detailed look at the currently available MOLES xsd documents (v3.2).  I can’t find any xsd docs that implement the MOLES v3.3 model.  I tried to make a valid instance doc for MO_Instrument.  IMHO the list of problems in the MO_Instrument schema (including 3 technically unusable attributes) is long and make it unusable with GeoSciML3.  I also found some things in the MO_Instrument xsd that are not evident or obvious from reading the UML.

1.  MO_Instrument has a mandatory attribute called “details” of type “MyProcessDetails”.  But the type for MyProcessDetails is not defined, so you cannot populate it.  (Nor is it an appropriate name for an element.)  This looks like it will be fixed in MOLES v3.3.

2.  MO_Instrument has a mandatory attribute called observedProperty, which also does not have a defined type and can’t be populated.  This attribute also conflicts with the O&M model of having observedProperty associated with the Observation, not the instrument.

3.  MO_Instrument has a mandatory attribute, inherited from MI_Instrument, called “citation”.  It is not an appropriate attribute type to describe an instrument, although it could be used to refer to a document describing the instrument.

4. MO_Instrument has a mandatory attribute, inherited from MI_Instrument, called “uses”, which references LE_Algorithm, described as “Details of the methodology by which geographic information was derived from the instrument readings”.  Neither the attribute, nor its description, are designed to accommodate our laboratory needs.

5.  MO_Instrument inherits two different attributes with the same name called “type”.  IMHO this is not good.  One is from MI_Instrument (see point 6 below), the other is a “by reference only” attribute whose use I cannot work out.

6.  The inherited MI_Instrument attribute called “type” uses an enumeration called MI_SensorTypeCode.  This enumeration list does not exist, so you can’t populate this attribute.

7.  MO_Instrument has an optional attribute called relatedParty.  This is a MOLES version of CI_Responsible party. There is an error in the MOLES schema, because when you try to create a relatedParty instance, you get into an infinite loop of related parties within parties within parties that will validate only when you finally encode an empty “relatedParty” element.

Additionally,

8.  MO_Process (and hence the link to OM_Process) does not exist in the MOLES 3.2 schemas.  This means that the MO_Acquisition class in the v3.2 schema specialises MI elements, not O&M.  As a result, MO_Acquisition in the MOLES 3.2 schema has relations to SF_Specimen and SF_SamplingFeature that are contrary to the general O&M Observation-Process model.  These design problems look like they will be fixed in MOLES 3.3.

I am happy to support further development of a MOLES model/schema, but the current schemas can’t be used with GeoSciML in their current form.

Cheers,
Ollie

------------------------------------------------------------------------------------------------
Ollie Raymond
National Advice,  Maps and Standards Project
Geoscience Australia

Address: GPO Box 378, Canberra, ACT, 2601, Australia | ABN: 80 091 799 039
Ph: (02) 62499575 | Fax: (02) 62499992 | Email: Oliver.Raymond at ga.gov.au
Web:  http://www.ga.gov.au/minerals/research/national/nat_maps/nat_geol_maps.jsp<http://www.ga.gov.au/geoscience/national>

Google Map<http://maps.google.com/maps?f=q&hl=en&geocode=&q=canberra+australia&ie=UTF8&ll=-35.344028,149.158362&spn=0.007684,0.016404&t=h&z=17&iwloc=addr&om=1>

-- This message was created with 100% recycled electrons --


-----Original Message-----
From: Bruce.Simons at dpi.vic.gov.au [mailto:Bruce.Simons at dpi.vic.gov.au]
Sent: Thursday, 11 March 2010 10:03 AM
To: Raymond Oliver
Cc: bryan.lawrence at stfc.ac.uk; Eric.Boisvert at rncan-nrcan.gc.ca; Guillaume.Duclaux at csiro.au; simon.cox at jrc.ec.europa.eu; steve.richard at azgs.az.gov; Terry.Rankine at csiro.au
Subject: RE: Fw: [moles] A question regarding Class Specialisation [SEC=UNCLASSIFIED]


Ollie,
I can't see the reason for 1 and 2.
< AFAICT, the MOLES subtyping of OM_Observation and OM_Process are all required because MOLES want to create new outbound associations from OM_Observation and OM_Process (eg; acquisition, computation, propertyLocation). >

It looks like MOLES have created the MO_Observation class so they can have an in-bound association from MO_ObservationCollection, which is a specialisation of ObservationCollection with attributes.  However, as there is already an association between ObservationCollection and OM_Observation this is unnecessary.
< ObservationCollection has been removed from the latest O&M v2.  So MOLES have to create their own class for it. >
As the other associations are outbound the only other benefit from specialising OM_Observation I can see is to restrict the result to a CV_DiscreteCoverage.  < I agree. > But as you say this seems unduly restrictive.

The MO_Acquisition attributes are inherited from MI_Operation, which is very 'remote-platform' centric (Description ="Description of the mission on which the platform observations are part and the objectives of that mission").  However, we should put the 'language' and the occasionally confusing documentation (citation ="character string by which the mission is known" but datatype = CI_Citation) aside. < I cringe every time I read the descriptive notes for MI classes and are asked to use them for describing our geological/geochemical needs.  Spiros from the MOLES team also recognises this problem... eg, “A specialisation of  LE_Algorithm it doesn’t seem appropriate , but can I use the class with a different definition from the ISO  standard?” My question is, why should we use classes from an ISO standard that is inappropriate for our needs?>

I prefer the MO_Acquisition-instrument-MO_Instrument pattern rather than the AnalyticalProcess:instrument:AnalyticalInstrument approach < I can see the benefit of having Acquisition and Computation associated with OM_Process rather than as specialisations of OM_Process.  It allows both Acquisition and Computation to be related to an Observation if necessary.> (note if the latter pattern is used AnalyticalInstrument should probably be a DataType rather than a FeatureType).  < Surely an instrument is a feature? Or is the big grey machine sitting in my laboratory a mirage.... >

I'm also comfortable with using citation:CI_Citation from MI_xx - if we want the capacity to reference the source documentation for an instrument, < Then we would need to be more explicit about how CI_Citation is to be used.  But the explanation of the use of CI_Citation is defined by the MI schema and we can’t edit that AFAIK. >  process etc then we should use CI_Citation.  From the notes it is unclear what the intention of citation is but I agree it is not useful for describing a machine.

The main question is should the process (as captured in AnalyticalProcess and MO_Acquisition) be a specialisation of OM_Process (...the base class for observation processes... or MI_Operation (= Designations for the operation used to acquire the dataset)? < Definitely OM_Process.  O&M is much better for us than MI. >

I like the MO_xx pattern where MO_Acquisition is an 'acquisition' property of  Process (I see no need for the MO_Process specialisation < You have to specialise OM_Process to be able to make outbound associations for computation and acquisition > ) and MO_Computation a computation property of a Process.  As such, I'd like to see Analytical Process a specialisation of MO_Acquisition, without the "instrument" attribute, and AnalyticalInstrument a specialisation of MO_Instrument.  The downside, if it is one, is that we become dependent on importing at least two extra schema into the instances. < Happy to mimic the MOLES 3.3 pattern here, but not use the currently available MOLES schema (v3.2).  See above analysis of the currently available MOLES xsd schema. >

Cheers
Bruce

GeoScience Victoria
AuScope Grid
Australian Spatial Research Data Commons

Ph: +61-3-9658 4502
Fax: +61-3-9658 4555
Mobile: +61 429 177155

<Oliver.Raymond at ga.gov.au>

10/03/2010 05:52 PM

To

<Bruce.Simons at dpi.vic.gov.au>, <bryan.lawrence at stfc.ac.uk>

cc

<Eric.Boisvert at rncan-nrcan.gc.ca>, <Guillaume.Duclaux at csiro.au>, <simon.cox at jrc.ec.europa.eu>, <Terry.Rankine at csiro.au>, <steve.richard at azgs.az.gov>

Subject

RE: Fw: [moles] A question regarding Class Specialisation [SEC=UNCLASSIFIED]










Sounds like the GeoSciML group should press ahead with a model for geochemistry.  I’ve attached a diagram showing a comparison of the relations that MOLES classes have with O&M and the relationships that our proposed GeoSciML LaboratoryAnalysis classes have with O&M.  I have found it useful to visualise the 2 models together.  You will see that there are some similarities, but some significant differences.

1.  LaboratoryAnalysis tends to use more of the core O&M classes, whereas MOLES has subtyped both Observation and SamplingFeature which change the associations between O&M and some other elements (eg; the MO_Observation result link is different to O&M, the associations between SamplingFeature and Observation are different in MOLES from O&M).  I was pretty happy with the generic O&M relations between SamplingFeature and Observation.

2.  The result link from MO_Observation is CV_DiscreteCoverage.  That seems limiting to me.  I would prefer to maintain the more generic O&M result link.

3.  MO_Acquisition is similar to AnalyticalProcess.  However, MO_Acquisition uses 19115-2 attributes whereas I think AnalyticalProcess uses more appropriate properties (eg, not CI_Citation).

4.  AnalyticalInstrument uses some simple hard-coded attributes to describe an instrument.  MO_Instrument uses CI_Citation which I don’t think is a good way to describe a machine.

5.  AnalyticalProcess attempts to model properties of an analytical session (ie, those properties that vary from day to day on a machine, like voltage, current etc).  I cannot see a similar function within MOLES.

Please note that the LaboratoryAnalysis package is very much still a work in progress.
          - I am a little uncomfortable that detection limits and errors are so far removed in the model from the actual result value.
          - I have not yet figured out the best way to handle standards and blanks associated with an analytical session.
          - There may be scope to make the AnalyticalProcess more generic
          - SessionDetails may need some work

Cheers,
Ollie


------------------------------------------------------------------------------------------------
Ollie Raymond
National Advice,  Maps and Standards Project
Geoscience Australia

Address: GPO Box 378, Canberra, ACT, 2601, Australia | ABN: 80 091 799 039
Ph: (02) 62499575 | Fax: (02) 62499992 | Email: Oliver.Raymond at ga.gov.au
Web:  http://www.ga.gov.au/minerals/research/national/nat_maps/nat_geol_maps.jsp<http://www.ga.gov.au/geoscience/national>

Google Map<http://maps.google.com/maps?f=q&hl=en&geocode=&q=canberra+australia&ie=UTF8&ll=-35.344028,149.158362&spn=0.007684,0.016404&t=h&z=17&iwloc=addr&om=1>

-- This message was created with 100% recycled electrons --


-----Original Message-----
From: Bruce.Simons at dpi.vic.gov.au [mailto:Bruce.Simons at dpi.vic.gov.au]
Sent: Wednesday, 10 March 2010 11:23 AM
To: Bryan Lawrence
Cc: Eric.Boisvert at rncan-nrcan.gc.ca; Guillaume.Duclaux at csiro.au; moles at ncas.ac.uk; moles-bounces at ncas.ac.uk; Raymond Oliver; simon.cox at jrc.ec.europa.eu; Terry.Rankine at csiro.au
Subject: Re: Fw: [moles] A question regarding Class Specialisation


Hi Bryan,
Thanks for the feedback.
It sounds like the 'acquisition' discussion was very stimulating. I'm sorry I missed it. Hopefully we can take it further if the workshop at eResearch in Brisbane later this year goes ahead.

Ollie is generating draft classes to deal with the geochemistry use case, so I'm confidant we will have tested these and have useful feedback for the MOLES group in mid - late 2010. Having the GeoSciML - Geochemistry task group and the MOLES group communicating their findings will no doubt benefit both groups.

Cheers
Bruce

GeoScience Victoria
AuScope Grid
Australian Spatial Research Data Commons

Ph: +61-3-9658 4502
Fax: +61-3-9658 4555
Mobile: +61 429 177155
Bryan Lawrence <bryan.lawrence at stfc.ac.uk>
Sent by: moles-bounces at ncas.ac.uk

09/03/2010 05:19 PM


To

Bruce.Simons at dpi.vic.gov.au

cc

Terry.Rankine at csiro.au, Guillaume.Duclaux at csiro.au, moles at ncas.ac.uk, simon.cox at jrc.ec.europa.eu, Eric.Boisvert at rncan-nrcan.gc.ca, Oliver.Raymond at ga.gov.au

Subject

Re: Fw: [moles] A question regarding Class Specialisation














Hi Bruce

> Did the MOLES meeting throw up anything useful to meet Steve and
>  Ollie's requirements?

I'll let Simon answer this one himself ... but my take on it is that
given your immediate timescales MOLES isn't ready for you and rather
than you using MOLES, we'd rather like to see what you do with O&M and
then ask whether MOLES needs extension.

We did have an extended discussion on your use case, and we do think we
will have it covered - but it exposed an interesting argument as to what
"acquisition" actually means.  I will put some notes up this week.

I think Simon's take on that is that acquisition is the process that
immediately precedes the production of a number.

Personally, I'm going to think this through some more: at the moment I
feel happier with acquisition being the process of obtaining a specimen
(in your use case) and subsequent analysis being just that ...
subsequent.

However that would put the "analysis" in the "data quality" branch, and
that needs thinking through - and might be too unnatural ...

> The email from Spiros suggests that they have hit the same wall we
>  did with SensorML, that it is too specific and doesn't handle the
>  general cases well.

No, I don't think that's what Spiros is implying at all. For sure we are
extending very significantly ISO19115-2, because on it's own it's too
specific - but I think it opens significantly more doors than sensorml,
and is preferable to a blank piece of paper as a starting point.

Spiros's point is a bit more technical ... about best practice in domain
modelling. We're all still novices here :-)

Cheers
Bryan

>
> Cheers
> Bruce
>
> GeoScience Victoria
> AuScope Grid
> Australian Spatial Research Data Commons
>
> Ph: +61-3-9658 4502
> Fax: +61-3-9658 4555
> Mobile: +61 429 177155
> ----- Forwarded by Bruce Simons/DPI/VICGOV1 on 09/03/2010 01:08 PM
>  -----
>
> <spiros.ventouras at stfc.ac.uk>
> Sent by: moles-bounces at ncas.ac.uk
> 06/03/2010 12:36 AM
>
> To
> <moles at ncas.ac.uk>, <simon.cox at jrc.ec.europa.eu>
> cc
>
> Subject
> [moles] A question regarding Class Specialisation
>
>
>
>
>
>
>
> I have a question regarding the appropriate use of  class
>  specialisation. EXAMPLE : the definition of ISO 19115-2 class
>  LE_Algorithm is :  Details of the methodology by which geographic
>  information was derived from the instrument readings,
> But I want to use this class  in MOLES3 with the definition: Details
>  of the ProsessStep underlying method  ( the attributes remaining
>  unchanged ) It seems to me that the definition for MOLES is more
>  generic than the ISO 19115-2. The 'LE_Algoritm' in MOLES3  is for
>  any ProcessStep not only for Instruments.
> A specialisation of  LE_Algorithm it doesn’t seem appropriate , but
>  can I use the class with a different definition from the ISO
>  standard? Thank you
> Spiros
>

--
Bryan Lawrence
Director of Environmental Archival and Associated Research
(NCAS/British Atmospheric Data Centre and NCEO/NERC NEODC)
STFC, Rutherford Appleton Laboratory
Phone +44 1235 445012; Fax ... 5848;
Web: home.badc.rl.ac.uk/lawrence

_______________________________________________
moles mailing list
moles at ncas.ac.uk
http://lists.ncas.ac.uk/mailman/listinfo/moles

"D卌#9ߓM4­Ÿԅ8Ԭ7㓽‑[1]8b隊Vu򪛚rۦk'(֢)ߢ*'ʞʧjW(z{bjPQ蚖\+╨‑uݾܢmSLSM����⪓h��.֞ꫡۜy֝j^vܢi'翔㓔㓽‑[1]*+¸霢{‑ڟm ޯ񎵿ŸԿ<񎵻"ͭ8ԟiǀ&"جzʨțXʇ텪޲*bz{mȞrG譩ݭ騽뢮랳񎵿ŸԿ<񎵷ڱૉl7!zz+޶آ隊Xz讙^jǧ؟ʘ^靺򭫮wj)]zWz+_ꬊ˞ݵ뭮'('b騵Ⱨm랲xjרʉ텨~檘ʧyاzf񎵿ϼSM����⪗(����҈{c幫‑r쉗y֞~ަ)඘zf񎵿ϼSM����⪛"ͭ㓝)󧮊[attachment "MOLESandLabAnalysis.jpg" deleted by Bruce Simons/DPI/VICGOV1]
________________________________
Ÿԟiǀ&,ޘڭǿ㓔㓲ܥx[1](dNPЂ8}4ӀQSLSNȳ{aN57ڱૉS+‑jwZ&!魲fr��❺+b{ajجꬢvr߉ק&^eʚ⾩^皝ߨʩʸ߅8ԅ8ԟiǀ&6Zڟۡ靭Ꞧǝi֩稭ʦ颱^w񎵱N57ڱૉpبۡz⢼+۞ʧ魡ayʩʸڰ꿔㓼SO󏔣S,ޘSM����⪒-ˡz쉸ܨ~؞碦'ڜ社ڝڞ޾*?㓼SO󏔣S}‑[1]ȳ{b­ʋj����筆+‑w镦zz-랝׫o*޶ꧺfץzע蛪.̬隝מڨɩ򲊢zƨޞZب+‑vڮ稚kƭz뺜؞w讦ܢ{Zw{aǦj)㓼󅸔ߩǀ&rhM<Ӎ,7>W稞ȝzay鯊'魭稭꫊{b
aǦj)㓼󅸔ߩǀ&,ޛ񎵹۲Ͼv짳ϝ)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20100311/e3b30ec9/attachment.htm>


More information about the GeoSciML mailing list