[auscope-geosciml] FW: MappedFeature [SEC=UNCLASSIFIED]

Boisvert, Eric Eric.Boisvert at RNCan-NRCan.gc.ca
Mon May 30 07:31:05 EDT 2011


>I'm not sure that I agree that GeoSciML is really the schema rather than the UML model.
 
GeoSciML is a Markup Language (as its name states), so I think it's the schema.  Bruce Johnson even suggested - a while ago -  that the instance was the real thing, since ways to document / constrain them will come an go (XSD, Schematron, UML are just fancy documentations) .
 
Eric

________________________________

De : auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] De la part de Laxton, John L.
Envoyé : 30 mai 2011 06:46
À : auscope-geosciml at lists.arcs.org.au
Objet : Re: [auscope-geosciml] FW: MappedFeature [SEC=UNCLASSIFIED]



Yes - GeoSciML is using nillable in exactly the same sense that INSPIRE is using voidable.

 

I'm not sure that I agree that GeoSciML is really the schema rather than the UML model. The UML and associated documentation is the primary means of communication of GeoSciML and I think this is showing the problems that arise when important information about GeoSciML is not in the UML.

 

John  

 

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: 30 May 2011 01:19
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [auscope-geosciml] FW: MappedFeature [SEC=UNCLASSIFIED]

 

Hi Marcus, 
The "or" is very important and I think the second reason is even more explicit for GeoSciML nillable properties than the INSPIRE General conceptual Model 'no data' reasons Michael Lutz provides. I would rewrite Michael's explanation for GeoSciML nillable properties as: 

"the characteristic is not present in the spatial object, but is present in the real world." 

This is consistent with your summary statement: 
"So we are using nillable where some property isn't present in our spatial objects ("poorly populated") but is applicable in the real world ("logically expected")." 

----------------------------------------------------
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:        "Sen, Marcus A." <mase at bgs.ac.uk> 
To:        "auscope-geosciml at lists.arcs.org.au" <auscope-geosciml at lists.arcs.org.au> 
Date:        27/05/2011 06:00 PM 
Subject:        Re: [auscope-geosciml] FW:  MappedFeature [SEC=UNCLASSIFIED] 
Sent by:        auscope-geosciml-bounces at lists.arcs.org.au 

________________________________




> -----Original Message-----
> From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope- <mailto:auscope-> 
> geosciml-bounces at lists.arcs.org.au] On Behalf Of
> Bruce.Simons at dpi.vic.gov.au
> Sent: 27 May 2011 02:33

> I think the GeoSciML Designers would agree with Clemens' observations.
> However, GeoSciML has (mostly) been designed as an implementation (ie
> physical) information model, not a conceptual or logical model. As such
> GeoSciML is really the schema, not the schema's visual representation
> (the UML). The Design team have agreed that to maximise
> interoperability, properties should be mandatory where it is sensible
> for them to be logically expected.  Due to poorly populated legacy
> datasets often these properties need to be nillable.
I don't follow why you say "However"? The example you give of poorly populated legacy datasets seems to accord with the reasons for representing two different kinds of "no data" in the INSPIRE General Conceptual Model as quoted by Michael Lutz: " The characteristic is not present or not applicable in the real world *or* the characteristic is not present in the spatial object, but may be present or applicable in the real world." (My emphasis as I think that is the *or* between the two no data types.) So we are using nillable where some property isn't present in our spatial objects ("poorly populated") but is applicable in the real world ("logically expected").

> Nillable therefore needs to remain as a tagged value.  Whether we also
> want to maintain the overhead of either <<voidable>> or UML notes is a
> documentation question.
I don't have any particular opinion on the solution but I can't see a relevant difference between GeoSciML and INSPIRE here. (Michael Lutz comment that "You can automatically apply default values of tagged values associated with a stereotype to UML elements carrying the stereotype in EA." does sound worth investigating, however.)

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 <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/20110530/b9a30378/attachment.htm>


More information about the GeoSciML mailing list