1

Re: Standardised naming of elements

Hi

A suggestion I would make is that it may make life easier if we were to use the same naming for elements in the Web Services (NBNWS) as are used in Recorder.

Some elements seem to be almost the same (e.g. TaxonVersionKey in NBNWS and TAXON_VERSION_KEY in Recorder)

However when I was looking for TaxonReportingCategory (as returned by NBNWS from TaxonomySearchRequest - see http://www.searchnbn.net/library/webser … nk01788330), I was totally confused as to how to get this from Recorder. The list of names in the TaxonReportingCategory appears to be the same as provided in the 'download list of taxon groups and keys' (available from http://www.searchnbn.net/library/webser … ources.jsp - incidentally the key is not named). I also came across a number of possibles in Recorder (e.g. Taxon_List_Item_Key) but the lack of common naming makes this very difficult to find (or maybe I just missed it).

The reason for this requirement is to enable us to design our web database to provide more efficient searching and provide greater compatibility with Recorder. So in our web database we would have fields named TAXON_VERSION_KEY but we might split out records into different tables by taxon group (e.g. birds, flowering_plant etc) so searching for Sciurus vulgaris (TVK=NBNSYS0000005108) would be limited to the 'terrestrial_mammal' table.

I believe that standardisation of names between elements (in NBNWS) and data fields (in Recorder) will make make it a lot easier to design compatibility. I guess someone may have a valid reason why this is not desireable but if not then I think that it would be easier to make the changes now before lots of web sites start consuming NBN web services.

Hope this makes sense :/

BTW if anyone can tell me what to use (table and field name) to build our query in Recorder to enable us to split our data by TaxonGroup (or TaxonReportingCategory or something else), I would be most grateful :)

Cheers

Nick

(ePlanning Project Manager) Aberdeenshire Council

2

Re: Standardised naming of elements

Hi Nick,

You've made several good points here, so I'll try and answer them as best as I can.

Nick wrote:

Some elements seem to be almost the same (e.g. TaxonVersionKey in NBNWS and TAXON_VERSION_KEY in Recorder)

Yep, the two are equivalent. For the XML schema we've adopted "CamelCase" formatting for element and attribute names. I think this is generally the agreed best practice convention for XML element naming. Though I agree using uppercase and underscores would be perfectly legal, we will continue sticking with convention.

Nick wrote:

The list of names in the TaxonReportingCategory appears to be the same as provided in the 'download list of taxon groups and keys'

The taxon groups are the TaxonReportingCategory names. I will update the data schemas to change TaxonGroup to TaxonReportingCategory so the data schema is more consistent. However, as I'm not a Recorder user I don't how that fits with recorder.

On a more general note, The XML schema has never been designed to map perfectly to recorder. Indeed, when the schema was originally spec'd the relationship with recorder was never considered. With hindsight perhaps some might think that was an oversight. Personally I don't think it was. The NBN Gateway web services are intended to provide data in a generic and flexible way for anyone, not just for Recorder. The Gateway is not a big version of Recorder; it has a different function, the underlying model is different and the data we hold simpler.

As a final observation, as a development team we don't have anything to do with Recorder, neither has there been any steer from the NBN Gateway funding partners, so being compatible has never really figured us.

cheers

Richard

[b]Richard Ostler[/b]
NBN Developer

3

Re: Standardised naming of elements

Hi Richard

I have no problem with your adopted formatting as it is clear where elements and data are the same.

I also recognise that the "Gateway is not a big version of Recorder" but I am assuming (rightly or wrongly) that a large component of the data that LRC's hold and share with the Gateway are stored on Recorder*. Recorder's data structure is extremely complex and I had merely suggested that it would be helpful if the two had obvious naming similarities. However if this is not feasible then maybe there is a need for someone to map between the Gateway and Recorder to help others design compatibility.

I believe that some compatibility may be useful, for example LRCs could provide their own web services that the Gateway (and others) could consume. Of course, this may not be part of the development plan for the Gateway but I like to think big and "what if we could ...." :)

* as part of the development of web services, it may be interesting to know this?

Anyway, thanks for all your work

Cheers

Nick

(ePlanning Project Manager) Aberdeenshire Council