[auscope-geosciml] GeologicEvent and GeologicFeature [SEC=UNCLASSIFIED]

Bruce.Simons at dpi.vic.gov.au Bruce.Simons at dpi.vic.gov.au
Mon May 9 20:58:21 EDT 2011


> Could we add a constraint to the model, that would not be too 
convoluted, to replace the lost cardinality rule between unit/structure 
and event?
It does get a bit tricky - we would need to change the cardinality on 
targetLink to 1..* and then specify that where the GeologicFeature is not 
a GeologicEvent, at least one GeologicFeatureRelation be a relationship 
with GeologicEvent.

Rather than trying to incorporate this into the actual model, I'd be 
inclined to leave all the relationships as optional in the model and then 
specify in the GeoSciML IWG Preferred Profile that that for all 
non-GeologicEvent GeologicFeatures at least one relationship with a 
GeologicEvent is provided.


----------------------------------------------------
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:   <Oliver.Raymond at ga.gov.au>
To:     <auscope-geosciml at lists.arcs.org.au>
Date:   10/05/2011 10:35 AM
Subject:        Re: [auscope-geosciml] GeologicEvent and GeologicFeature 
[SEC=UNCLASSIFIED]
Sent by:        auscope-geosciml-bounces at lists.arcs.org.au



You are right Bruce, we don’t actually need a GeologicHistory subtype.  
GeologicFeatureRelation/target/GeologicEvent does the same job.
 
Just one more thing.  The generic nature of GeologicFeatureRelation in 
Option B loses our ability to dictate the 1..* (nillable) cardinality 
between units (and structures) and their ages in the model.  Could we add 
a constraint to the model, that would not be too convoluted, to replace 
the lost cardinality rule between unit/structure and event?
 
Cheers,
Ollie
 
 

From: auscope-geosciml-bounces at lists.arcs.org.au [
mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of 
Bruce.Simons at dpi.vic.gov.au
Sent: Tuesday, 10 May 2011 10:20 AM
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [auscope-geosciml] GeologicEvent and GeologicFeature 
[SEC=UNCLASSIFIED]
 
Option B is my preferred choice.  It looks like a more consistent and 
extendable pattern. I do think its important, based on the previous 
discussion, to change GeologicEvent to a type of gsml:GeologicFeature 
rather than gml:Feature (sorry John!). 

Having removed the constraint I'm not convinced we need the 
GeologicHistory subtype of GeologicFeatureRelation. The following works: 

<GeologicUnit gml:id=”unit1”> 
            <targetlink> 
                        <GeologicFeatureRelation> 
                                    <relationship>depositional 
age</relationship> 
                                    <sourceRole>dated geologic 
unit</sourceRole> 
                                    <targetRole>depositional event 
age</targetRole> 
                                    <target> 
                                                <GeologicEvent> 
 <eventProcess>deposition</eventProcess> 
                                                 
<olderNamedAge>Silurian</oldernamedAge> 
                                                </GeologicEvent> 
                                    </target> 
                                    <source xlink:href=”#unit1”/> 
                        </GeologicFeatureRelation> 
            </targetlink> 
</GeologicUnit> 

However, I'd be happy with either Option B or my suggested change. 

As for the use of preferrredAge ... 

Bruce
----------------------------------------------------
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:        <Oliver.Raymond at ga.gov.au> 
To:        <auscope-geosciml at lists.arcs.org.au> 
Date:        10/05/2011 10:07 AM 
Subject:        Re: [auscope-geosciml] GeologicEvent and GeologicFeature 
[SEC=UNCLASSIFIED] 
Sent by:        auscope-geosciml-bounces at lists.arcs.org.au 




I agree with John that Option B appears more easily extensible.  As 
pointed out by Bruce, I would remove the GeologicHistory constraint on 
“source” and just leave the constraint on “target” in Option B.  Option B 
also brings a degree more consistency to the treatment of all associations 
between GeologicFeatures.  I think Bruce’s point about the geologicHistory 
tag being searchable in Option A is also handled in Option B, eg, 
  
Option A 
<GeologicUnit gml:id=”unit1”> 
            <geologicHistory> 
                        <GeologicEvent> 
 <eventProcess>deposition</eventProcess> 
             <olderNamedAge>Silurian</oldernamedAge> 
                        </GeologicEvent> 
            </geologicHistory> 
</GeologicUnit> 
  
Option B 
<GeologicUnit gml:id=”unit1”> 
            <targetlink> 
                        <GeologicHistory> 
                                    <relationship>depositional 
age</relationship> 
                                    <sourceRole>dated geologic 
unit</sourceRole> 
                                    <targetRole>depositional event 
age</targetRole> 
                                    <target> 
                                                <GeologicEvent> 
 <eventProcess>deposition</eventProcess> 
                                                 
<olderNamedAge>Silurian</oldernamedAge> 
                                                </GeologicEvent> 
                                    </target> 
                                    <source xlink:href=”#unit1”/> 
                        </GeologicHistory> 
            </targetlink> 
</GeologicUnit> 
  
The GeologicHistory xml in Option B is a bit messier, but the event age is 
still searchable via a slightly longer path. 
  
And here’s a thought to stir the pot – maybe John could put “preferred 
age” into the <relationship> tag.  The description of the type of event is 
provided by <targetRole> and <eventProcess>, so maybe <relationship> could 
be used to indicate that it is John’s “preferred age”?  (Ollie retires to 
a safe distance out of Bruce’s range….) 
  
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 62479992  |  Email: 
oliver.raymond at ga.gov.au  |  Google Map 
_______________________________________________________________________ 
  
--- 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 Laxton, 
John L.
Sent: Friday, 6 May 2011 6:59 PM
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [auscope-geosciml] GeologicEvent and GeologicFeature 
[SEC=UNCLASSIFIED] 
  
Folks, 
  
I think option A is a bit less extensible and generic. For example in 
INSPIRE we have added GeomorphologicFeature as a sub-type of 
GeologicFeature, with an optional association to GeologicUnit to describe 
the material associated with the GeomorphologicFeature (if any). Under 
option A this will require its own geologicHistory association, as will 
any other types of GeologicFeature added in the future. Under option B our 
association to GeologicUnit would become another subtype of 
GeologicFeatureRelation. 
  
So of these two I think I would go for Option B, BUT I still think what I 
first proposed is the simplest and involves by far the least change to the 
existing model: leave GeologicEvent as it is (don’t make it a 
GeologicFeature) and have a new subtype of GeologicRelation 
(GeologicEventRelation) targeting GeologicEvent. This option involves the 
creation of one new feature – end! 
  
John 
  
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: 06 May 2011 05:04
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [auscope-geosciml] GeologicEvent and GeologicFeature 
[SEC=UNCLASSIFIED] 
  
Option A – you can order geologic events by having the right kind of 
geologic relation (‘predecessor’). 
Absolute ordering using integers does not work for overlapping events. The 
geologic timescale works by having identifiable points which serve as the 
beginning or end of eras of various rank. 
  
From: auscope-geosciml-bounces at lists.arcs.org.au [
mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of 
Bruce.Simons at dpi.vic.gov.au
Sent: Friday, 6 May 2011 11:50 AM
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [auscope-geosciml] GeologicEvent and GeologicFeature 
[SEC=UNCLASSIFIED] 
  
Option A 
I can live with option A, although I can't see how to readily order the 
GeologicEvents. 

Option B 
The constraint on the relationship in Option B would need to be lifted 
(GeologicEvents can be related to each other - in fact this is a bonus 
allowing relating GeologicEvents from different provinces). 
Removing the constraint, and adding a "rank:integer" property to 
GeologicFeatureRelation to cater for ordering (are there other uses for 
this property?), would also work, and negate the need for the extra 
GeologicHistory class. 

Option A has the advantage that a tag <geologicHistory> will be 
searchable. Option B (without the special GeologicHistory class) will 
require a search on GeologicFeatureRelation where the target or source is 
a GeologicEvent. 

Bruce
----------------------------------------------------
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:        <Oliver.Raymond at ga.gov.au> 
To:        <auscope-geosciml at lists.arcs.org.au> 
Date:        06/05/2011 10:10 AM 
Subject:        Re: [auscope-geosciml] GeologicEvent and GeologicFeature 
[SEC=UNCLASSIFIED] 
Sent by:        auscope-geosciml-bounces at lists.arcs.org.au 
 





Hi all, 
 
I attach 2 options of what I think the UML could look like given the 
options presented by Marcus, John, Alistair and Bruce.  Firstly I should 
say here that the association between Unit/Structure and Event is pretty 
fundamental to geology and requires an explicitly named association (ie: 
geologicHistory) rather than using a non-specialised 
GeologicFeatureRelation and a vocabulary of relation types (sorry 
Alistair). 
 
Option A. 
 
We retain the geologicHistory association between GeologicUnit/Structure 
and GeologicEvent.  ie, geologicHistory effectively becomes a special case 
association between  particular GeologicFeatures, the same as we have 
already done with the definingStructure association between GeologicUnit 
and GeologicStructure.  This involves the least amount of change to the 
model and schemas from Version 2. 
 

 
Option B. 
 
We make all special associations between GeologicFeatures into constrained 
subtypes of GeologicFeatureRelation.  This would include GeologicHistory 
and DefiningStructure, and would make our treatment of associations 
between all GeologicFeatures consistent.  (Bruce, could you please provide 
more detail or an example of how to use this type of model in ordering 
events.  Are the constraints in the GeologicHistory class OK for your 
idea?) 
 

 
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 62479992  |  Email: 
oliver.raymond at ga.gov.au  |  Google Map 
_______________________________________________________________________ 
 
--- 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 
Bruce.Simons at dpi.vic.gov.au
Sent: Friday, 6 May 2011 9:39 AM
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [auscope-geosciml] GeologicEvent and GeologicFeature 
 
An advantage with creating  a new sub-type of GeologicFeatureRelation for 
GeologicEvents is that it would allow adding a property to deal with the 
'order' of the events. This is specified in the NADM Conceptual Model but 
left out of earlier versions of GeoSciML as being too hard to implement. 

Bruce 


----------------------------------------------------
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 
 
-----Original Message-----
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: Thursday, 5 May 2011 10:37 PM
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [auscope-geosciml] GeologicEvent and GeologicFeature 
 
You would have to query all targetlinks from a GeologicUnit to find those 
which targeted GeologicEvents, and then query the targetlinks of those 
GeologicEvents to get the geological history. It sounds a bit complicated 
but if you think it is practical..... 
 
John 
 
-----Original Message----- 
From: auscope-geosciml-bounces at lists.arcs.org.au [
mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Alistair 
Ritchie 
Sent: 05 May 2011 13:11 
To: auscope-geosciml at lists.arcs.org.au 
Cc: auscope-geosciml at lists.arcs.org.au 
Subject: Re: [auscope-geosciml] GeologicEvent and GeologicFeature 
 
Is such specialization necessary? Events can be sensibly related to all 
other GeologicFeatures, including themselves. 
 
Seems to be introducing more complexity into the model when 
GeologicFeatureRelation, and the appropriate vocabularies, would suffice. 
 
On 05/05/2011, at 20:45, "Laxton, John L." <jll at bgs.ac.uk> wrote: 
 
> Yes - I think you are going to have to define a new sub-type of 
GeologicFeatureRelation (like BoundaryRelationship) specifically targeting 
GeologicEvent. 
> 
> I originally proposed a new sub-type of GeologicRelation and to avoid 
this that it was proposed to make GeologicEvent a type of GeologicFeature, 
which still requires a new relation type albeit at one level lower...... 
> 
> John 
> 
> -----Original Message----- 
> From: auscope-geosciml-bounces at lists.arcs.org.au [
mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Alistair 
Ritchie 
> Sent: 05 May 2011 11:19 
> To: auscope-geosciml at lists.arcs.org.au 
> Cc: auscope-geosciml at lists.arcs.org.au 
> Subject: Re: [auscope-geosciml] GeologicEvent and GeologicFeature 
> 
> You would have to replace the geologicHistory association with a 
relationship defined using GeologicFeatureRelationship, yes? 
> 
> This would allow semantic richness using the role properties on the 
relationship class. 
> 
> 
> On 05/05/2011, at 19:45, "Sen, Marcus A." <mase at bgs.ac.uk> wrote: 
> 
>> If GeologicEvent is made a GeologicFeature will it still be appropriate 
to have the geologicHistory property included as a property of 
GeologicFeature? 
>> 
>> Other properties currently in GeologicFeature but not GeologicEvent 
are: 
>> 
>> observationMethod - guess that is applicable to a GeologicEvent as well 

>> purpose - can this apply to a GeologicEvent? 
>> occurrence - Seems to make sense as e.g. mapping location of epicentre 
of an earthquake. Distinct from the mapped features delimiting e.g. 
GeologicUnits that have been affected by certain GeologicEvents. 
>> targetLink - the property that people want on GeologicEvent that 
started the discussion 
>> 
>> (classifier and metadata properties are defined separately for both 
feature types.) 
>> 
>> Marcus 
>> 
>> 
>> -- 
>> 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. 
>> _______________________________________________ 
>> 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 
_______________________________________________ 
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. 
 
 
 

-- 
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.
_______________________________________________
auscope-geosciml mailing list
auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml

㓽‑[1]ȳ{ch'‑SLSN˲9CC⎅G񎵱N5;"ͭ8ԟiǀ&Nzfݪ|֜gɚɊ'w讦텫bڕʧ
~'^ؚez*kzjw(*ₛ㓔㓽‑[1]کjh~+luz趧‑uZם(kƭy߅8ԅ8ԟiǀ&«a뭅
꫊𮫭zw(ǧ텧(*ₛh·SO񎵿ϼSNȳ{aN57ڱૉH+-Ʝ'&▫razۨr+jwkzj/zǬ
SO񎵿ϼSM⪛"ͭ*.ޭ瞊zf)ޮ+W騶'򶗬zw^z۫隊W^랊׫l2צjw]z˫&Ɋ)똢櫺z-j롢
yۨǜi'ꫭ鲢{az)ߢ*'r޶)톫‑SO󏔣S}‑[1]ʥ4󍴲,ޘ^jǜ{"uꭅ秾*螧)트
-+‑SO󏔣S}‑[1]ȳ{oŸԧnʿ_______________________________________________
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/20110510/f7f24acc/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 84092 bytes
Desc: not available
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110510/f7f24acc/attachment.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 88640 bytes
Desc: not available
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110510/f7f24acc/attachment-0001.jpeg>


More information about the GeoSciML mailing list