1 Reply by Matt_tullie

  • Matt_tullie
  • Veteran
  • Offline
  • From: Carlisle, Cumbria
  • Registered: 18-05-2007
  • Posts: 166

Re: R6 Data organisation?

We are just about to start on the data transfer process from R3 to R6.
This means a big shift in the way our people interact with the data.

I would be interested to know how other Record centres organise their data in the R6 hierarchies available.

For example, how do folk use their survey hierarchies - for data providers or specifically for survey types or programs?
Have you implemented the full sites/subsites hierarchy or did you come up against perception/reporting problems that made that difficult?

I appreciate that from a databse p.o.v. it doesn't theoretically matter, but I would be keen to avoid pitfalls, especially with multiple users interfacing it, each with their own perceptions of how to organise information.
After all, some of our volunteers only interact with computers with us, and have no wider use of them.

Also I am sure their are conflicts when reporting on information, conflicts that stem from an object being lower down the hierarchy than it should be for the reporting method used.

I suspect everyone has their "If I were to start from scratch I would definitely do it this way!" statements.
I would be happy to hear them.
Screenshots welcome.

Ta

MAtt

Biological Data Officer
Tullie House
Carlisle

Cumbria Biodiversity Data Centre
Tullie House Museum

Matt_tullie's Website

2 Reply by charlesroper

  • charlesroper
  • charlesroper
  • Digital Development Manager
  • Offline
  • From: Field Studies Council
  • Registered: 26-03-2006
  • Posts: 906

Re: R6 Data organisation?

Regarding surveys, we use them much like folders you'd find in Windows. That is, we use them as a way of categorising sets of data. We also create a discrete survey where it seems logical to create one; if a real survey has been carried out and we have the data in a discrete set, for instance. Here's a tip: if you have several surveys from a data provider, put the initials of the organisation or individual in front of each survey. This way, the surveys will sort together in a more useful way. Screenshot here.

Locations are something I wish we could start again. Using the full hierarchy is not a problem; it's very useful in reporting terms. It's the proliferation of "one off" locations we have that are a problem. As a rule of thumb, try to only create locations - or location hierarchies - for sites that are defined as sites somehow. For example, you'd create locations for SSSI's, nature reserves, defined survey areas, etc. You'd create locations where it makes sense to hold that data in a structured way. For everything else (verges beside roads, random spots, back gardens, etc. - the locations that usually accompany ad hoc records) simply use the free text Location Name field. It's also useful to create location hierarchies with a 'dummy' parent. You can see that in action here; note that the HWAONB parent locations aren't real locations, but instead provide a way of logically grouping sets of related locations.

Create some data protocols and make sure everyone knows them and sticks to them. Create some data to demonstrate the protocols. Try to create things like locations, individuals and organisations, terms lists and so on centrally then export them out to others if you can, otherwise it's all to easy to get lumbered with multiple entries for the same thing. Rob Bradley did a lot of work for the Scottish Wildlife Trust setting up their data protocols and Recorder guidance. It might be worth contacting them to see what that work looks like.

That's all I can think of for now; hope it helps.

Charles Roper
Digital Development Manager | Field Studies Council
http://www.field-studies-council.org | https://twitter.com/charlesroper | https://twitter.com/fsc_digital

charlesroper's Website

3 Reply by Darwyn Sumner (LERC)

  • Darwyn Sumner (LERC)
  • Veteran
  • Offline
  • Registered: 07-06-2006
  • Posts: 176

Re: R6 Data organisation?

On the matter of Location hierarchies.
In our LRC, as an aid to providing services based upon different District, City and County authorities, we have an hierarchical structure which is headed by our LRC region (a VC if you're lucky enough to have one that matches well enough), followed by County/City/District and then on to individual Parishes (again we also provide parish based services).
All our Locations are then placed into the correct parish. We achieved this by "Cut"ting the Location, using the "Find on map" command, select the parish (oh yes, you will need a map layer of your parishes which are all linked to their Locations), use the "Associated locations" button to go to that parish then paste the Location into it.
This may be rather time-consuming at first but it provides several benefits.
The hierarchy is relatively straightforward to navigate provide you have some familiarity with your parishes, you avoid having to interpret long lists of Locations, you are are carrying out some form of validation as you do it (e.g an incoming record has a parish name which disagrees with the grid reference).
It is also possible to write XMLs which recurse down through the hierarchy and thus pick up statistics from all Locations in a District (e.g. for Local Development Framework such as areas of Calcareous grassland)

We also arrange individual Local Wildlife Site compartments as subsites under the main LWS site.

As a National Recording Scheme organiser I don't go down to this level of detail. I use the same methodolgy above to place my Locations into Vice County hierarchies.

So if I was starting again my first step would be to obtain the VCs from NBN and to import the ones you need as polygons onto a named map layer. Then obtain administrative boundaries from the OSLOs (Ordnance Survey Licensing Officers) of your partners (they must surely do this - how can you provide services if you haven't got their boundaries?) and place this onto a separate layer. If possible get the parishes too and do the same. Then hand-write your Location hierarchy down to the level of parish and link every one to its mapped object. Then try an import and move your Locations into the appropriate part of the hierarchy. And do use the Location's Designations facility liberally.

Hope that helps

4 Reply by james_cpbrc

  • james_cpbrc
  • New member
  • Offline
  • Registered: 06-06-2006
  • Posts: 1

Re: R6 Data organisation?

Hello Charles,

"Locations are something I wish we could start again. Using the full hierarchy is not a problem; it's very useful in reporting terms. It's the proliferation of "one off" locations we have that are a problem."

Problems with ad hoc recording sites is something I've heard of before (from Sally Rankin I think).
I think we're still using this method of doing things.  What do you think are the problems we'll face long term in doing so, and is it worth the pain of rebuilding the location hierarchies?  I'm reluctant to take on a heap of work (or at least for the data officers to take on a heap of work) for the sake of it.  We're currently moving from R2002 to R6 - would this be an opportunity to do so?

Any thoughts gratefully received,

James

Cambs and Pboro BRC