[GeoSciML] WFS querying of properties specified with xlink:href

Boisvert, Eric Eric.Boisvert at RNCan-NRCan.gc.ca
Wed Oct 10 08:16:14 EDT 2012


My argument against using hlink:href as a queryable property is that xlink:href are XML serialisation artefacts and not part of the model.  Serialisation model is not Query model. 

I always believed that serialisation was disconnected from the query model - in fact, you can have you WFS to serialised the response as KML.  XPath in the filter is just a way to express a path between the feature in context and a property you want to filter, the response in GML is constrained by other conditions, such as the maximal number of features (refering to an element that is not serialised in this response), already serialised features (hlink:href to a local entity), self reference and implementor decision, which will all create a xlink:href in some cases, and not in other cases.

The other argument is that forcing people to query the hlink:href value means (suggests ?) that properties of the refered feature are out of reach (or are they ? - if they aren't, what's the point of querying the xlink:href ?).  Querying the xlink:href of a GeoSciML association like this

property/@xlink:href = some_url 

is equivalent to
 
property/Feature/gml:identifier = some_url

(it the identifier is the same as the xlink:href - otherwise, how can one possibly query a xlink:href is the value is not related to the refered feature identity ?).  
I know many WFS actually serialise some xlink:href as WFS FeatureId=<id> requests, and this is precisely the problem, how can you query this ?

As for vocabulary item, my understanding (when we switched to SKOS encoding) was that ControlledConcept was the GeoSciML proxy, so the right way to query a feature through a controlled concept was

Eg: GeologicUnit/geologicUnitType/ControlledConcept/identifier = 'http://resource.geosciml.org/classifier/cgi/geologicunittype/0014'

Because ControlledConcept is the object that represents a vocabulary in the model, even if the vocabulary itself is serialized as SKOS (or some other formalism)

This is why I'm from separation of serialisation and query models (insert joke about quebecers here if you want)

My two cents




-----Message d'origine-----
De : geosciml-bounces+eric.boisvert=rncan-nrcan.gc.ca at lists.opengeospatial.org [mailto:geosciml-bounces+eric.boisvert=rncan-nrcan.gc.ca at lists.opengeospatial.org] De la part de Sen, Marcus A.
Envoyé : 10 octobre 2012 05:27
À : portele at interactive-instruments.de; A mailing list for GeoSciML
Cc : Tertre Francois
Objet : [GeoSciML] WFS querying of properties specified with xlink:href

Clemens and GeoSciML listers,

Some time ago we discussed the issue of using @xlink:href's for remote property values and querying them in a WFS service.

In a meeting with Clemens Portele in Edinburgh in February 2011, which Tim summarised to the list on 7 March 2011, Clemens raised a concern that querying on the value of an xlink:href value was not strictly allowable under the rules of WFS/FES (Web Feature Service / Filter Encoding Specification). The property value should really be what is found by dereferencing the href in the GML property model. However, at the time, testing using @xlink:href in the XPath expressions in a fes:ValueReference element worked successfully both in Snowflake Software's GoPublisher WFS and in Clemens' XtraServer software.

Since then we have happily been using these in queries. However, now I look back, I can't find a definitive decision that this is OK as far as the FES spec is concerned. My reading is that attribute values are allowed in the XPath and we are allowed to address "components" of a property but it isn't unambiguous.

The issue has arisen again for us because BRGM have just tested querying our latest Snowflake GeoSciML v3 WFS and it doesn't like the use of @xlink:href in the query. I have confirmed with Snowflake software that they have, indeed, made the behaviour more restrictive than it used to be so queries that used to work no longer do. This is going to be a serious problem for querying GeoSciML features in a WFS as so many properties use our pattern of dictionary URIs in an xlink:href attribute.

In order to ask Snowflake to change their software behaviour back again, I need some kind of authoritative declaration that this is valid behaviour. Or do current WFS and FES standards, in fact, not really support the kind of dictionary queries we want to do? This could be a problem.

Comments?

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.



More information about the GeoSciML mailing list