[Auscope-geosciml] Technology implementation vs. recent spec & policies

Rob.Atkinson at csiro.au Rob.Atkinson at csiro.au
Sun Aug 1 20:45:11 EDT 2010


So, in order to use the name, the client DB needs to promise to act as a register, with persistent ids, and the rest of the system needs to accept this contract – i.e. no-one else can create a new id for boreholes without declaring it as a local id, and providing the means to resolve the original registered id – either a lookup service or an attribute that specifies the original id (a gml:name with a codespace at least).

It’s an open question (at least in my mind) about the best way to publish such system interoperability contracts – when we “bind to a controlled vocabulary” we are making similar contracts – so perhaps it’s formally part of a service profile description.  This is  a motivation for being able to register models in a sensible way  (less opaque than XMI in SVN, but adhering to transparent governance) – because often these relationships are explicit in the model, and perhaps what we need is knowledge of the implementation binding – i.e. a tagged value that tells us the namespace (codespace) that will be used for references to a modelled data type.

In this case, a profile of GeoSciML would decorate the Borehole type with a tagged value that specifies the codespace. Somehow the codespace needs to be resolved to the point of truth – in this case the “client DB” – i.e. would expect a service registry that provides the WFS Borehole service endpoint for the codespace, but could provide alternative service endpoints for different protocols – e.g. a vocab (validation) service.

Which then of course leads onto how to describe service architectures systematically so such contracts can be shared across systems of systems reliably ☺

Rob

From: Duclaux, Guillaume (CESRE, Kensington)
Sent: Monday, 2 August 2010 10:29 AM
To: Atkinson, Rob (CLW, Lucas Heights)
Cc: auscope-geosciml at lists.arcs.org.au; Fraser, Ryan (CESRE, Kensington); Tan, Florence (CESRE, Kensington); Angreani, Rini (CESRE, Kensington); Cox, Simon (CESRE, Kensington); Alistair.Ritchie at dpi.vic.gov.au
Subject: Re: [Auscope-geosciml] Technology implementation vs. recent spec & policies

The gml:id for the borehole (à la AuScope) is created on the  on-the-fly by GeoServer following a rule defined in the config file. The gml: id (à la AuScope once again) contains the "name" of the borehole as it registered in the client DB.

Gilly


On 02/08/2010, at 7:24 AM, Atkinson, Rob (CLW, Lucas Heights) wrote:


Persistent means there is a register ☺ i.e. something that acts like a register for this. It could be a list of things published in a spreadsheet – it’s the behaviour that counts.
(note the difference between “here is the result of your query” and “here is a register of things” – the semantics of a query says nothing about the process by which things come into existence and are given ids.)

Rob

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 Bruce.Simons at dpi.vic.gov.au<mailto:Bruce.Simons at dpi.vic.gov.au>
Sent: Friday, 30 July 2010 4:31 PM
To: Duclaux, Guillaume (CESRE, Kensington)
Cc: Fraser, Ryan (CESRE, Kensington); auscope-geosciml at lists.arcs.org.au<mailto:auscope-geosciml at lists.arcs.org.au>; Tan, Florence (CESRE, Kensington); Angreani, Rini (CESRE, Kensington); Cox, Simon (CESRE, Kensington); Atkinson, Rob (CLW, Lucas Heights);Alistair.Ritchie at dpi.vic.gov.au<mailto:Alistair.Ritchie at dpi.vic.gov.au>
Subject: Re: [Auscope-geosciml] Technology implementation vs. recent spec & policies


Surely the gml:id for the Borehole should be a document only id and shouldn't persist.

The srsName reference is to an internal id, which in turn refers to an extrernal persistent srsName register entry, so I'm missing why  we need to know “what is the register in which the object id is declared?”

Cheers
Bruce

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


<Guillaume.Duclaux at csiro.au<mailto:Guillaume.Duclaux at csiro.au>>

30/07/2010 04:14 PM

To

<Rob.Atkinson at csiro.au<mailto:Rob.Atkinson at csiro.au>>

cc

<bruce.simons at dpi.vic.gov.au<mailto:bruce.simons at dpi.vic.gov.au>>, <Ryan.Fraser at csiro.au<mailto:Ryan.Fraser at csiro.au>>, <Robert.Woodcock at csiro.au<mailto:Robert.Woodcock at csiro.au>>, <Simon.Cox at csiro.au<mailto:Simon.Cox at csiro.au>>, <Alistair.Ritchie at dpi.vic.gov.au<mailto:Alistair.Ritchie at dpi.vic.gov.au>>, <Florence.Tan at csiro.au<mailto:Florence.Tan at csiro.au>>, <Ben.Caradoc-Davies at csiro.au<mailto:Ben.Caradoc-Davies at csiro.au>>, <Rini.Angreani at csiro.au<mailto:Rini.Angreani at csiro.au>>, <auscope-geosciml at lists.arcs.org.au<mailto:auscope-geosciml at lists.arcs.org.au>>

Subject

Re: Technology implementation vs. recent spec & policies







Thanks Rob for your response.

Ok, so it might be unsafe to use a response as a register unless the response's gml:id remains through time.
I have 2 files, one encoding boreholes information and another encoding Observation&Measurements done along one particular borehole.

Let say the gml:id for the borehole curve will persist, would the following encoding be correct for the sa:samplingLocation in the observation file?

              <sa:LocatedSpecimen>
                   <sa:sampledFeature ... />
                   <sa:relatedObservation>
                        <om:Observation>
...
</om:Observation>
                   </sa:relatedObservation>
                   <sa:materialClass>...</sa:materialClass>
                   <sa:samplingTime>...</sa:samplingTime>
                   <sa:samplingLocation xlink:href="http://services-test.auscope.org/nvcl/wfs?request=getFeature&typeName=gsml:Borehole&FeatureID=BOREHOLE.UDD1420#BOREHOLE.UDD1420.LINESTRING">
                       <!-- the xlink:href points to the geometry of the borehole -> sa:shape/gml_Cruve gml:id -->
                       <gml:LineString>
                           <gml:posList>141.0 142.0</gml:posList>
                       </gml:LineString>
               </sa:LocatedSpecimen>




On 30/07/2010, at 1:00 PM, Atkinson, Rob (CLW, Lucas Heights) wrote:

This brings me to my 2 questions -

2. Question: Should we follow the recent OGC policy about nameSpace and deliver resolvable URI for SRS or stick to the WFS spec (on which the technology is built) and deliver srsName in a URN format or (worse) in a non resolvable URL format?
So, in the AuScope WFS responses, shall we encode GDA94 as:
                                                                                                               http://www.opengis.net/gml/srs/epsg.xml#4983 (works with GeoServer)
                                                                                                               or  http://www.opengis.net/def/crs/EPSG/0/4983  (fully resolvable and nicely encoded - I'm a bit influenced maybe)

RA: I think only the first one is legal in the context of the WFS spec.  Consistent policy and implementation in a spec by OGC are not guaranteed, and in this case the spec predates the URI policy.

3. Question: According to the GeoSciML v2+ spec, the srsName of the gml:Envelope defined in gsml:Borehole/gsml:indexData/gsml:BoreholeDetails/gsml:coredInterval/ should be defined byRefence, after the gsml:Borehole/sa:shape/sa:_Curve of the borehole. How do we achieve this with GeoServer if it needs to stick to the WFS 1.1 specs?

This is the gsml:coredInterval defintion:"Interval(s) within the borehole from which core was recovered Use GM_Envelope with 1-D CRS corresponding to borehole curve shape."

This definition is valid according to GML 3.1 spec, where it says that SRS properties can be inherited in a feature or feature collection:

GML 3.1 spec, part 8.3: Spatial reference system used in a feature or feature collection
<<For convenience in constructing feature and feature collection instances, the value of the srsName attribute on
the gml:Envelope (or gml:Box) which is the value of the gml:boundedBy property of the feature shall be
inherited by all directly expressed geometries in all properties of the feature or members of the collection,
unless overruled by the presence of a local srsName. Thus it is not necessary for a geometry to carry an
srsName attribute if it uses the same coordinate reference system as given on the gml:boundedBy property of
its parent feature. Inheritance of the coordinate reference system continues to any depth of nesting, but if
overruled by a local srsName declaration, then the new coordinate reference system is inherited by all its
children in turn.
Notwithstanding this rule, all the geometries used in a feature or feature collection may carry srsName
attributes, in order to indicate the reference system used locally, even if they are the same as the parent.>>

To me GeoServer should be able to automatically define the srsName byReference (ie a reference to the _Curve gml:id -> srsName="#boreholeID_CurveId").

RA: a reference can be to anything with an id – so the question is “what is the register in which the object id is declared?”.

IMHO it would be unsafe to use a response as a register – though one could say the response was bound by a contract that the gml:ids of some attributes were defined in a (possibly virtual) register. I.e. it’s probably OK as long as the gml:id were not going to change for the same object.

Making the register entry referencable (i.e.  given an id, can something reference it later) may require an additional interface (in this case perhaps getGMLObject(id)), or again you could define a contract which says that a copy of the referenced object must always be shipped with the referencing object). This might be a profile that enforces cardinality of attributes in a FeatureType, or you may even need a special FeatureType that bundles the reference and the referring object into a single Feature to ensure this referential integrity.


I guess the real question is about  spec vs. implementation...

I hope my message will make sense to you guys.

Cheers

Gilly



*[2]         Cox S., Daisey P., Lake, R., Portele C., Whiteside A. (eds.), "OpenGIS Implementation Specification #02-023r4: OpenGIS– Geography Markup Language (GML) Implementation Specification, version 3.1.1", January 2005

Dr Guillaume Duclaux

Mineral Down Under Flagship & AuScope Grid
CSIRO Earth Science and Resource Engineering

Phone: +61 8 6436 8728  | Fax: +61 8 6436 8559  | Mobile:  +61 422 289 732

guillaume.duclaux at csiro.au<mailto:guillaume.duclaux at csiro.au> | www.csiro.au<http://www.csiro.au/> |
Address: Australian Resources Research Centre, 26 Dick Perry Avenue, Kensington WA 6151

PLEASE NOTE
The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference.

Please consider the environment before printing this email.






Dr Guillaume Duclaux

Mineral Down Under Flagship & AuScope Grid
CSIRO Earth Science and Resource Engineering

Phone: +61 8 6436 8728  | Fax: +61 8 6436 8559  | Mobile:  +61 422 289 732

guillaume.duclaux at csiro.au<mailto:guillaume.duclaux at csiro.au> | www.csiro.au<http://www.csiro.au/> |
Address: Australian Resources Research Centre, 26 Dick Perry Avenue, Kensington WA 6151

PLEASE NOTE
The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference.

Please consider the environment before printing this email.




?婒i??必,睕??箖箖羚台(dNP陔8?}?笄QS{aN57猱?S?‑古wZ?音?穛f猛j)??b┐aj堿伉鮈v叵孜&?^e?熅)^Z霅?妐?萲8埧8婒i???根!a]m縤死嘎眯萇h倚&滸兗w醨51N57猱?ph窩azⅣ+^'梢瞴y?妐??箖鯔箖?睕S?x 毄R-az楓??艇芒傂剔"?孜?$~??豏?箖鯔箖}??逢b ?】鱈y賜m?‑?w垣津z-??卻*瑗聬zf?蚰z蛁詠?*.晃炸?^缽駓斧rz?鼓?種h?‑v?梁(?zz\?傂霈f?┐Z?{a夸)箖?婒i??叵烘<粈,??W?蒼y濈'璥賥匪kb?a夸)箖?婒i??必,睒醨59蛢>v鴔鯔)


Dr Guillaume Duclaux

Mineral Down Under Flagship & AuScope Grid
CSIRO Earth Science and Resource Engineering

Phone: +61 8 6436 8728  | Fax: +61 8 6436 8559  | Mobile:  +61 422 289 732

guillaume.duclaux at csiro.au<mailto:guillaume.duclaux at csiro.au> | www.csiro.au<http://www.csiro.au/> |
Address: Australian Resources Research Centre, 26 Dick Perry Avenue, Kensington WA 6151

PLEASE NOTE
The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference.

Please consider the environment before printing this email.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20100802/12d68544/attachment.htm>


More information about the GeoSciML mailing list