[auscope-geosciml] Opportunities for re-factoring GeoSciML?[SEC=UNCLASSIFIED]
Bruce.Simons at dpi.vic.gov.au
Bruce.Simons at dpi.vic.gov.au
Mon Jun 13 19:03:28 EDT 2011
Last year I suggested moving GeologicUnit and GeologicStructure out of
GeoSciML-Core, but received no support then. Clearly I am in favour of an
improved refactoring but there is potentially considerable discussion
required to determine what should be in GeoSciML-Core. Simon has
suggested one option, I'd prefer to see EarthMaterial, GeologicFeature,
Collection remain in GeoSciML-Core, with GeologicUnit, GeologicStructure,
GeologicAge and GeologicRelation have their own package.
Given how close the Edinburgh meeting is, and the need to determine how to
refactor I think we have missed the opportunity and will need to leave it
to an OGC DWG.
Regarding instance documents, like Eric I have not produced any yet - none
of the current GeoSciML v3 ones validate in Altova XMLSpy so AFAIC we do
not yet have a valid schema. As such any decision will not set back work
I have done (trying to fix gsml:Borehole).
----------------------------------------------------
Bruce Simons
Senior Information Geoscientist
IUGS-Commission for Geoscience Information Oceania Councillor
GeoScience Victoria/Australian Spatial Research Data Commons
Level 9, 55 Collins St
PO Box 4440
Melbourne, Victoria, 3001
Australia
Ph: +61-3-9658 4502
Fax: +61-3-9658 4555
Mobile: +61 429 177155
From: "Boisvert, Eric" <Eric.Boisvert at RNCan-NRCan.gc.ca>
To: <auscope-geosciml at lists.arcs.org.au>
Date: 14/06/2011 03:13 AM
Subject: Re: [auscope-geosciml] Opportunities for re-factoring
GeoSciML?[SEC=UNCLASSIFIED]
Sent by: auscope-geosciml-bounces at lists.arcs.org.au
It depends if there is a strong requirement to have that version of the
schema before Edinburgh meeting for testing. Honestly, I just started to
work on instance documents so I don't have a large backlog to deal with.
Changes to the schema at this point (and if I understand correctly) is
mostly rework the schemaLocation, namespaces (and prefixes) of the same
instance documents and not a change to the model itself so it's not a
moving target as far as the model is concerned. In short, if the work on
RC3 schemas instance is meant to provide input for final version in
Edinburgh and those instance are about the same model (minus the packaging
artefacts), I don't see it as a big problem (exclusing the fact that we
will punish those who made their instances / services early and reward
procrastinators like me) - we can still use those instance has a way to
test the model. On the other hand, if this actually changes a significant
part of the model that was meant to be tested and the schema are delayed
up to the eleventh hour.. I think it's too late. If we count repackaging,
and generating / testing schemas involving 2 persons 13 time zones apart,
we are looking probably at one week before the schemas are ready.
BTW. is there a plan to put into place a formal RC (request change)
mechanism à la OGC or is this question to be lumped into a bigger
discussion about having GeoSciML as a formal OGC DWG ?
Eric
De : auscope-geosciml-bounces at lists.arcs.org.au [
mailto:auscope-geosciml-bounces at lists.arcs.org.au] De la part de
Oliver.Raymond at ga.gov.au
Envoyé : 13 juin 2011 09:46
À : auscope-geosciml at lists.arcs.org.au
Objet : Re: [auscope-geosciml] Opportunities for re-factoring
GeoSciML?[SEC=UNCLASSIFIED]
There are a couple of mutual dependency glitches to iron out before
Simon's suggestion could be done:
1. GeoSciMLCore-GeologicEvent <-> GeologicStructure-DisplacementValue =
mutual dependency between GeoSciML-Core and GeologicStructure
2. (GeologicStructure-GeologicStructure -> GeoSciML-Core-GeologicFeature)
+ (GeoSciMLCore-GeologicEvent -> GeologicStructure-DisplacementValue) =
mutual dependency between GeoSciML-Core and GeologicStructure
Apart from the above dependency glitches which would need remodelling, we
are a long way down the track of version 3 now. I'm currently putting the
finishing touches to the v3 rc3 schemas and was hoping that this RC would
be the last one. A refactor at this stage (with 3 new app schemas and
namespaces) would be a pretty major reconstruction of what we've been
working on with v3 RC's to date (and Francois and I will effectively
discard our last week's work on generating/checking the v3 rc3 schemas if
we want to refactor GeoSciML now).
I would love to say "Put this off until version 4". However, I am loathe
to give anyone a further chance to label GeoSciML as a "moving target"
with yet another refactoring at version 4. So if we want to do any more
package refactoring, I would strongly urge that we do it now or not at
all. If the GeoSciML team is amenable to Simon's refactoring suggestions,
Francois and I would stop work on the current v3 rc3 schemas and we'll
generate a new set of schemas after the model is refactored.
Given the implications of Simon's suggestion, could I ask for comments
from all of the GeoSciML team with some urgency. My personal feeling is
one of ambivalence to further splitting up of the GeoSciML-Core
application schema. I'm not convinced of the need for it, but I would not
be opposed to the idea if the majority of the GeoSciML community was for
it.
Cheers,
Ollie
_______________________________________________________________________
Ollie Raymond
Project Leader
National Geological Maps and Data Standards Project
Geoscience Australia
Interoperability Working Group
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 624799917 | Email:
oliver.raymond at ga.gov.au
_______________________________________________________________________
--- This message was created with 100% recycled electrons ---
From: auscope-geosciml-bounces at lists.arcs.org.au [
mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of
Simon.Cox at csiro.au
Sent: Monday, 13 June 2011 4:51 PM
To: auscope-geosciml at lists.arcs.org.au
Subject: [auscope-geosciml] Opportunities for re-factoring GeoSciML?
GeoSciMLers:
Following the recent changes to the model relating to relations and
derivations, I’d like to ask if this opens up (again) the opportunity for
some package refactoring?
E.g.
i . make GeoSciML-core just contain the GeologicFeature, GeologicRelation
and GeologicAge leaf packages (this makes sense as geology is a historical
science) and
ii, iii, iv., move GeologicMaterial, GeologicUnit and GeologicStructure,
into their own Application Schemas.
DefiningStructure and BoundaryRelationship should be moved in
GeologicStructure, but otherwise I think the dependencies are pretty clean
now.
Simon
Simon Cox | Research Scientist
CSIRO Earth Science and Resource Engineering
ARRC, PO Box 1130, Bentley WA 6102, Australia
Tel +61 8 6436 8639 | Mob +61 403 302 672
Email simon.cox at csiro.au | Web http://www.csiro.au
_______________________________________________
auscope-geosciml mailing list
auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110614/c320362e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 3627 bytes
Desc: not available
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110614/c320362e/attachment.gif>
More information about the GeoSciML
mailing list