[GeoSciML] FW: Conformance classes and GeoSciML

Duffy, Tim trd at bgs.ac.uk
Thu Jun 6 03:20:49 EDT 2013


FYI what Simon said in March 2012
cheers
Tim

________________________________
From: auscope-geosciml-bounces at lists.arcs.org.au [auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Simon.Cox at csiro.au [Simon.Cox at csiro.au]
Sent: 09 March 2012 09:56
To: auscope-geosciml at lists.arcs.org.au
Subject: [auscope-geosciml] Conformance classes and GeoSciML

I’ve just had a discussion with Tim about the future of GeoSciML in OGC and INSPIRE.
I understand that there may be some confusion about the relationship between packaging and conformance classes, and some potential looming issues about simplification requests.

The OGC specification-for-specifications is designed to allow standards to be constructed incrementally, building on each other, or building up greater and greater complexity within a single standard.
This is achieved by being very clear about how dependencies are managed, both within and between specifications.

The unit of re-use is the Requirements Class (each one being tested by a corresponding Conformance Class).
The reason for this is to keep the whole thing manageable – each standard will have between 1 and maybe 30 RCs, and conformant implementations can clearly explain which classes (modules) they implement and which they don’t.

Nothing in a single requirements class is optional – every requirement must be satisfied by the standardization target, all or nothing.
In practice this means that ‘options’ are managed by placing the corresponding requirements in separate RCs, so you claim conformance to a whole class.
You increment the capabilities of your product by implementing a whole new class, etc
Thus dependencies are recorded at this level – a Requirements Class has dependencies on other RCs, arising from dependencies between requirements, but not specified normatively at that level.

Another key point is that dependencies are acyclic.
If you think about it, mutual dependencies mean that you can’t implement either without the other, so functionally you have a single class.

For standards specified using UML, a requirements-class appears as a UML package.
One of the motivations behind the package re-factoring that I proposed, and Ollie implemented, last year was to ensure that GeoSciML packaging matched the requirements for an OGC specification – no cycles.

For standards specified using XML Schema, a requirements-class corresponds to an XML namespace, the ‘targetNamespace’ of the schema.
This is consistent with GML’s UML-XML encoding rule, which was followed by GeoSciML.

So GeoSciML is in good shape for formalization consistent with OGC Policy
– you will have 15 Requirements Classes for implementations(*) corresponding to the UML packages stereotyped <<ApplicationSchema>>
and 15 (?) Requirements classes for XML instance documents, corresponding to the XML namespaces.
Easy-peasy.

What you can’t do is mix and match classes from different packages in a single requirements class, or even worse subsets of attributes/associations of classes.
If the UML packaging does not correspond with the desired requirements/conformance class structure, then one or other will have to change.
But whatever you do, you must to retain the acyclic nature of the package dependency graph, which I recall was hard-won in 2011.

(*)implementations might be XML schemas, database schemas, spreadsheets, ontologies, etc.

Hope this helps.

Simon

From: Cox, Simon (CESRE, Kensington)
Sent: Monday, 30 January 2012 6:03 PM
To: auscope-geosciml at lists.arcs.org.au
Subject: RE: OGC TC Austin [SEC=UNCLASSIFIED]

The key thing is to be very very clear about what the standardization target is.

For GeoSciML you probably have two standardization targets:

1.       For the model (UML) the standardization target is the implementation (e.g. an XML schema, or a database schema). This gets tested by checking that the schema includes all the stuff in the model. Use of an automated UML-XML generator more or less ensures that, but you still need to state the requirements something like “shall implement all classes in Package X with all attributes and associations having the correct target and cardinality”. The test will probably be ‘inspect the schema and verify that ...’ etc.

2.       For the XML schema, the standardization target is XML instance documents. In this case the requirement is “a document containing an instance of ClassA shall be well formed and valid” and the corresponding test is “validate the document against the XML schema document foo.xsd [and the schematron document faz.sch (if applicable)]” etc.
Note that the XML Schema for GeoSciML is an instance of the standardization target for the GeoSciML UML model, so it should be either asserted or proved that is does indeed satisfy the requirements and pass the tests related to this. It is also an instance of a GML Application Schema, so should also satisfy the requirements for these as specified in the GML spec, in this case as specified both in Clause 21 and Annex E. Other XML implementations could be generated that also satisfy the model, though if they also satisfy the GML Application Schema rule they wouldn’t be very different to what you have generated.  But there can and should be other implementations for other platforms, so the requirements related to the UML model are needed for those.

Simon

From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Laxton, John L.
Sent: Monday, 30 January 2012 5:35 PM
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [auscope-geosciml] OGC TC Austin [SEC=UNCLASSIFIED]

Hi Ollie,

I think the ball is now in our court and the next step is producing a specification document. My understanding is that the pattern we need to follow is that used by CityML – is that right Simon? Tim, Marcus and I were looking at the conformance class section of CityML last week. I had assumed these would represent different levels of conformance (like for the service specifications) but all it seemed to say was that data using a particular package should validate against the schema for that package. If that is all there is to conformance classes it shouldn’t be too onerous specifying them!

The question on taking this forward is who has time to get down to writing the document....

John

From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Oliver.Raymond at ga.gov.au
Sent: 29 January 2012 21:45
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [auscope-geosciml] OGC TC Austin [SEC=UNCLASSIFIED]


Hi all,



Who is charged with moving the arrangements with OGC forward?  John, Francois, Simon, someone else?  Do I understand correctly that we need some kind of formal arrangement with OGC before we can move forward with the documentation required to become an OGC standard?



Ollie

_______________________________________________________________________

Ollie Raymond

Section Leader
National Geological Maps and Data Standards Section<http://www.ga.gov.au/minerals/projects/current-projects/geological-maps-standards.html>
Geoscience Australia

Interoperability Working Group<https://www.seegrid.csiro.au/wiki/bin/view/CGIModel/InteroperabilityWG>
IUGS Commission for the Management and Application of Geoscience Information

Address: GPO Box 378, Canberra, ACT, 2601, Australia | ABN: 80 091 799 039
Ph: +61 2 62499575 | Fax: +61 2 62499917 | Email: oliver.raymond at ga.gov.au<mailto:oliver.raymond at ga.gov.au> | 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: auscope-geosciml-bounces at lists.arcs.org.au<mailto:auscope-geosciml-bounces at lists.arcs.org.au> [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Boisvert, Eric
Sent: Sunday, January 29, 2012 11:37 PM
To: auscope-geosciml at lists.arcs.org.au<mailto:auscope-geosciml at lists.arcs.org.au>
Subject: [auscope-geosciml] OGC TC Austin



Are there any activities related to the OGCfication of GeoSciML planned for Austin TC in March.  I try to decide if it worth going or not.  I would normally go for water but HydroDWG has a separate meeting



Eric



_______________________________________________

auscope-geosciml mailing list

auscope-geosciml at lists.arcs.org.au<mailto:auscope-geosciml at lists.arcs.org.au>

http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml

--
This message (and any attachments) is for the recipient only. NERC
is subject to the Freedom of Information Act 2000 and the contents
of this email and any reply you make may be disclosed by NERC unless
it is exempt from release under the Act. Any material supplied to
NERC may be stored in an electronic records management system.

________________________________
This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20130606/48cb66cb/attachment-0001.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT00001..c
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20130606/48cb66cb/attachment.asc>


More information about the GeoSciML mailing list