[auscope-geosciml] RE : RE : RE : EarthMaterial package [SEC=UNCLASSIFIED]

Wed Oct 27 17:38:54 EDT 2010

>Governance is an aspect of an interoperability contract, as far as we are 
concerned - so a single authority may quite naturally have different sets 
of policies for different components

In fact the Interoperability Working Group currently governs both the 
GeoSciML and EarthResourceML namespaces. The work done on these packages 
is done by different groups, both working to the IWG 'guidelines'.

As the development teams grow (more community engagement) it would make 
sense to have various packages modified by experts in those fields, rather 
than relying on the current group of 'generalists'!  Whatever facilitates 
this is where she should be heading.

Cheers
Bruce Simons

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

From:   <Rob.Atkinson at csiro.au>
To:     <auscope-geosciml at lists.arcs.org.au>
Date:   28/10/2010 08:33 AM
Subject:        Re: [auscope-geosciml] RE :  RE :  RE :  EarthMaterial 
package [SEC=UNCLASSIFIED]
Sent by:        auscope-geosciml-bounces at lists.arcs.org.au

Governance is an aspect of an interoperability contract, as far as we are 
concerned - so a single authority may quite naturally have different sets 
of policies for different components - even components of the same type. 
GeoSciML may have a core they maintain as stable and domain-specific 
extensions that are devolved to more active development teams.  Likewise, 
within the same set of policies, a different life-cycle status may apply. 
I'd characterise all of these as part of the governance aspect.

Whether this means we need different namespaces is I think bound up in 
versions - if we have versions in namespaces then by default we must have 
different namespaces for each application schema, since they may be 
versioned independently - or we lose the benefits of encapsulation.

As we move to a model and model-derived artefact repository that handles 
dependencies and versions we will need to start understanding and 
capturing a set of policies and lifecycle status around which a 
methodology can be matured.  Please send your suggestions in :-) In the 
meantime Simon is looking into this on behalf of ISO and I'm attempting to 
focus this around what can be automated and impacts the entire 
model-driven archtecture chain of dependencies.

Rob

________________________________
From: auscope-geosciml-bounces at lists.arcs.org.au 
[auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Boisvert, Eric 
[Eric.Boisvert at RNCan-NRCan.gc.ca]
Sent: Wednesday, 27 October 2010 8:46 PM
To: auscope-geosciml at lists.arcs.org.au
Subject: [auscope-geosciml] RE : RE : RE : EarthMaterial package 
[SEC=UNCLASSIFIED]

My understanding was that namespaces were also representing governance (in 
addition to preventing name clashes).  Is this suggesting that these part 
would/should be governed independently ? (ie, "let's outsource 
EarthMaterial")

Eric

________________________________
De: auscope-geosciml-bounces at lists.arcs.org.au de la part de 
Rob.Atkinson at csiro.au
Date: mer. 2010-10-27 05:36
À: auscope-geosciml at lists.arcs.org.au
Objet : Re: [auscope-geosciml] RE : RE : EarthMaterial package 
[SEC=UNCLASSIFIED]

my understanding is its one namespace per application schema - but I know 
simon has looked into this in more detail and I'll bow to his superior 
knowledge.  I'm not convinced multiple namespaces is a problem.

I quite like looking at an element in instance document and being able to 
see the source of the relevant schema definition easily, but really tools 
should be able to cope either way.

Rob

________________________________________
From: auscope-geosciml-bounces at lists.arcs.org.au 
[auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Boisvert, Eric 
[Eric.Boisvert at RNCan-NRCan.gc.ca]
Sent: Wednesday, 27 October 2010 8:30 PM
To: auscope-geosciml at lists.arcs.org.au; auscope-geosciml at lists.arcs.org.au
Subject: [auscope-geosciml] RE :  RE :  EarthMaterial package 
[SEC=UNCLASSIFIED]

My point is that it can be done without having multiple namespaces, it 
just compartimentation of the xsd files structure in such a way that you 
can import a xsd while ignoring the others.

Or am I missing something again ?.

________________________________

De: auscope-geosciml-bounces at lists.arcs.org.au de la part de 
Rob.Atkinson at csiro.au
Date: mer. 2010-10-27 05:20
À: auscope-geosciml at lists.arcs.org.au
Objet : Re: [auscope-geosciml] RE : EarthMaterial package 
[SEC=UNCLASSIFIED]

you can reuse part of a model (or a schema) without being affected by 
every change in any related part (encapsulation). Hopefuly we can get to 
the point where the core model is stable and we are adding new modules or 
improving specific aspects. This means namespaces - since we have one per 
application schema.

We will just need tools to help us building configurations - humans dont 
buold instances - so more namespaces isnt such a problem in reality is it?

Rob

________________________________
From: auscope-geosciml-bounces at lists.arcs.org.au 
[auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Boisvert, Eric 
[Eric.Boisvert at RNCan-NRCan.gc.ca]
Sent: Wednesday, 27 October 2010 8:04 PM
To: auscope-geosciml at lists.arcs.org.au
Subject: [auscope-geosciml] RE : EarthMaterial package [SEC=UNCLASSIFIED]

what's the benefit of having many namespaces again ?

________________________________
De: auscope-geosciml-bounces at lists.arcs.org.au de la part de 
Oliver.Raymond at ga.gov.au
Date: mar. 2010-10-26 22:09
À: auscope-geosciml at lists.arcs.org.au
Objet : [auscope-geosciml] EarthMaterial package [SEC=UNCLASSIFIED]

Hi all,

The v3 RC2 model is on the verge of schema generation.

Simon mentioned in passing to me that we might consider extracting the 
EarthMaterial leaf package out of the quite large GeoSciML-Core package 
and into its own Application Schema.

As far as I can see, this would not introduce any dependency problems 
(GeoSciML-Core schema would just import the EarthMaterial schema), and it 
would be a fairly simple thing to implement even at this late stage in v3 
RC2.

Could I get feedback from everyone about whether they think this is a good 
idea.

Thanks,
Ollie

------------------------------------------------------------------------------------
Ollie Raymond

National Advice, Maps and Data Standards Project
Geoscience Australia

GeoSciML Design Group
IUGS Commission for the Management and Application of Geoscience 
Information
Interoperability Working Group

------------------------------------------------------------------------------------

Address: GPO Box 378, Canberra, ACT, 2601, Australia | ABN: 80 091 799 039
Ph: +61 2 62499575 | Fax: +61 2 62499992 | 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
>
National geological maps  
http://www.ga.gov.au/minerals/research/national/nat_maps/nat_geol_maps.jsp
Geoscience Australia web services  
http://www.ga.gov.au/resources/applications/ogc-wms.jsp
------------------------------------------------------------------------------------

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

_______________________________________________
auscope-geosciml mailing list
auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml

_______________________________________________
auscope-geosciml mailing list
auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
_______________________________________________
auscope-geosciml mailing list
auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
_______________________________________________
auscope-geosciml mailing list
auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml

Notice:
This email and any attachments may contain information that is personal, 
confidential, legally privileged and/or copyright.No part of it should be reproduced, 
adapted or communicated without the prior written consent of the copyright owner. 

It is the responsibility of the recipient to check for and remove viruses.
If you have received this email in error, please notify the sender by return email, delete 
it from your system and destroy any copies. You are not authorised to use, communicate or rely on the information 
contained in this email.

Please consider the environment before printing this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20101028/50283161/attachment.htm>