[auscope-geosciml] FW: Identifiers and encodings - items for discussion
Simon.Cox at csiro.au
Simon.Cox at csiro.au
Tue May 29 20:38:03 EDT 2012
A couple of interesting issues in this INSPIRE mail:
1. INSPIRE possibly moving away from codespace/localName style of identification and towards acceptance of http URIs
2. Is adapting rather than adopting existing standards like CityGML and GeoSciML wise?
From: owner-inspire-dataspec at jrc.ec.europa.eu [mailto:owner-inspire-dataspec at jrc.ec.europa.eu] On Behalf Of Clemens Portele
Sent: Tuesday, 29 May 2012 11:19 PM
To: Data Specifications Drafting Team; JRC Data specification team
Subject: Identifiers and encodings - items for discussion
I have some comments for discussion related to the Implementing Rule and Technical Guideline updates.
These are in essence two separate issues that I would like to raise for discussion, but as they are related to architectural questions (fortunately mainly from a data interoperability point of view, so we can ignore the network services for a moment) I would like to bring them up together. These are not new issues and they have been discussed before, but with the IR getting closer to the ISC and the data specs getting closer to publication, I think it is time to revisit them. I am happy to move these to JIRA, but I thought it might be a good idea to initially raise them for discussion here:
1. INSPIRE Identifiers
We all know the history that has led to the current approach with the data type with the namespace / local id properties. For the conceptual model, this is still adequate, in particular with the wording in the Directive. Looking at the implementation, however, both INSPIRE and the web has moved on. In INSPIRE, there is no longer an expectation that there will be any other network than the web. In the web, http URIs now play much more the role of identifiers than of temporary addresses. I think this is now the right time to reflect this in our technical guidance and also in the IR. Later on, this might be too late.
- Remove the lexical constraint from the namespace and local id properties in the IR (I expect that Germany will submit such a comment to the EC in the current "review" phase)
- In D2.5/D2.7 we should include a recommendation that the concatenation of namespace and local id is a URI that identifies the spatial object (and if possible also returns a representation of the object)
- In D2.7 we should clarify that going forward the Identifier-typed properties will not be encoded in the GML encoding (tagged value xsdEncodingRule set to "notEncoded") and the INSPIRE identifier should be encoded in the gml:identifier property (as it is now); this removes a redundancy in the GML encoding
In particular with the surprisingly (to me) high number of Annex III objects that may (or must) carry an INSPIRE identifier I think this would be important and helpful in the implementation.
For those that cannot support URIs, gml:identifier does not require the use of URIs identifying the object, so their identifiers may be represented, too.
Following this approach would also allow to get rid of the (need for a) register for object identifier namespaces as the namespaces would be URIs and the usual mechanisms for URIs would apply here. Namespace URI assignment would essentially be decentralised without the risk of conflicts.
[Related to this, Keith and I are working on a short document on the identifier/URI topic as discussed a few weeks ago on this list. We think this could become an annex of D2.5. I hope that we have a draft soon - i.e. within the next two weeks, which will mostly depend on me getting to do my tasks for it!]
2. Use of existing encodings
To get INSPIRE data into use, it seems important that we do not create too many INSPIRE-specific technology requirements. However, in INSPIRE we sometimes seem to consider that INSPIRE is big enough to justify that. Two encoding examples that I have raised before, but that I would like to bring up again after looking at the 3.0rc1 versions of the BU and GE data specs.
For both, existing encodings exist and that could be used (CityGML for BU and GeoSciML for the Geology Core in GE). The underlying conceptual models have been used in the creation of the INSPIRE core models and these are mostly simple profiles of these (possibly with small extensions). That means that these established schemas could be used to encode INSPIRE data and those that can read those encodings can directly use them. If we require data providers, data users and software developers to support an INSPIRE encoding in addition to the encoding that has been developed by the international community and which other users will request, then I think we are just creating additional work for everyone.
I do not know, if there are other cases, but at least for these two I think in clause 9 the data specs should specify how INSPIRE data can be encoded using the existing schemas, i.e. a mapping would need to be documented and we wouldn't derive GML application schemas from the relevatn INSPIRE application schemas in UML.
I do not know, if 3.0rc1 is still the latest version or if this has been addressed already.
portele at interactive-instruments.de<mailto:portele at interactive-instruments.de>
+49 228 9141073 (office)
+49 151 15298497 (mobile)
interactive instruments Gesellschaft für Software-Entwicklung mbH
Trierer Str. 70-72, 53115 Bonn, Germany
Geschäftsführer: Reinhard Erstling, Karla Hinzer, Clemens Portele, Bernd Weidner
Amtsgericht Bonn, HRB 3872
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the GeoSciML