Authority Files and Mandatory Input Fields

[Lucy FJ]

Hello all,

I have two unrelated questions: 

1. I have modified several authority files through the Reference Data Manager and would like to see these modified versions in the database but we cannot find them. Where do they reside? 

2. There are many input fields (boxes) on the input forms that we do not need but they appear to be mandatory. We have loaded up the sample reference data. Is there a simple way to makes these fields optional without needing to change the program? i.e. I am looking for a user method of being able to ignore these fields. 

Thank you very much for any help,

Lucy

 

[Adam Cox]

Hi Lucy, hopefully this information will address your questions.

1. The authority files are actually only used during the package install process.  Once you have installed the package, any changes you make in the RDM are not reflected in the files themselves, but are contained in your database.  You can export the schema that you've created to a skos file, but I don't know of a way to retro-actively create authority files (i.e. based on changes that have been made through the RDM.  As I mentioned in this considerations document, personally I recommend making all of the changes to the authority files before the package install, because then you can reinstall without any trouble.

2. You'll need to modify the forms themselves, which has come up here and here (and perhaps elsewhere) on the forum already.  It's a bit of an involved process, so it would be best to get help from someone with good javascript and html skills.

Adam

[Lucy Fletcher-Jones]

Hi Adam,

Thank you once again for your very helpful input. 

The documentation was very helpful in explaining how to create our own customized authority files using a text editor but I have just a couple more questions on loading our own customized files. Do you place the customized authority files in the custom database, currently called 'my-hip-app' and then run the following command to load them: 

$ python manage.py packages -o load_concept_scheme -s 'path to authority files directory' 

We will only be using a very few authority files for the first phase of our project. Will Arches work with just a few authority files, or do we need to load 'dummy' ones? So far we have been using the full set of sample files so haven't tried this out. 

Thank you very much,

Lucy

Lucy Fletcher-Jones 

Egypt Database Project

TMP Room 2181, HUSS Building AUC New Campus

Tel: 02 2615 1760

Mobile: 010 1633 8367

--
-- To post, send email to arches...@googlegroups.com. To unsubscribe, send email to archesprojec...@googlegroups.com. For more information, visit https://groups.google.com/d/forum/archesproject?hl=en
---
You received this message because you are subscribed to a topic in the Google Groups "Arches Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/archesproject/QOUoumJpLHc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to archesprojec...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Adam Cox]

Hi Lucy, sorry for the late reply on this.

There are two ways to load authority files: by setting the CONCEPT_SCHEME_LOCATIONS in your settings.py and then running

python manage.py packages -o install

This will completely reinstall your packages and replace the existing database, which means that any resources you've entered will be lost, and any changes you've made in the RDM will be lost (because those changes are stored in the database, not in the authority files themselves.

The other way to load authority documents is by using the command you listed already.  You don't actually need to have the authority files in the my_hip_app directory (though it would probably be good to place them somewhere close to it at least) because you specify the directory location in the command itself.  If, for example, you have them in C:\Projects\authority_files, your command would look like this:

python manage.py packages -o load_concept_scheme -s 'C:/Projects/authority_files'

However, I believe that running that command will add all the schemes in your authority documents to the database, and not overwrite any existing ones that match.  I don't there is a way to "unload" existing concepts, so if you try this repeatedly you will end up with duplicate concepts.

Personally, I recommend making substantial changes to the authority documents themselves prior to the installation.  That way you can reinstall the package as much as you need (because editing graphs require a reinstall) without losing any information.

Hope that helps!

Adam

--
-- To post, send email to arches...@googlegroups.com. To unsubscribe, send email to archesproject+unsubscribe@googlegroups.com. For more information, visit https://groups.google.com/d/forum/archesproject?hl=en

---
You received this message because you are subscribed to a topic in the Google Groups "Arches Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/archesproject/QOUoumJpLHc/unsubscribe.

To unsubscribe from this group and all its topics, send an email to archesproject+unsubscribe@googlegroups.com.

[Lucy FJ]

HI Adam,

Sorry for this late thank you but we made a breakthrough in our Arches project last week (see separate post) and I was showing the project to my manager. 

Your answer is helpful but I am still not sure about authority files that we will not be using. if we change the files themselves as you suggest prior to installation, should we simply delete the information in the authority files we are not using or not load them? 

Thank you, 

Lucy

--
-- To post, send email to arches...@googlegroups.com. To unsubscribe, send email to archesprojec...@googlegroups.com. For more information, visit https://groups.google.com/d/forum/archesproject?hl=en

---
You received this message because you are subscribed to a topic in the Google Groups "Arches Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/archesproject/QOUoumJpLHc/unsubscribe.

To unsubscribe from this group and all its topics, send an email to archesprojec...@googlegroups.com.

[Adam Cox]

Hi Lucy, I'd recommend that you take a look at the graphs themselves, because they are the most important part of the database.  On the graphs, you'll see that there are authority documents at the end of many branches: the graphs define what authority documents must be included on install.

It really sounds like you are actually interested in redefining the structure of the database, which means modifying the graphs.  I've put together some information about that here, so you can see what kind of level of effort it will take to accomplish that.  That said, if you do not want to modify the graphs, you could just make an authority document blank by deleting all of its content.  This will lead to some empty dropdown menus in the forms...

[Lucy FJ]

Hi Adam,

Thank you for your reply. On consideration, we don't wish to completely change the structure of the database, but we do wish to add new data fields (nodes and edges) and change some labels on the input forms.

 I do have a question on keeping to standards. On the Heritage Resource E18 graph, Place, E53 has a branch to 'Administrative Sub division.E48' which has an 'Administrative_Subdivision_Type E.55 and a corresponding authority file. We would like to put in Egyptian Governorates  as our only administrative sub division and have a drop down list of those governorates. Can we simply use the 'Administrative_Subdivision_Type.E55' for the list of Governorates, and remove the 'name' box on the form? It seems that this is bending the rules. Alternatively, do we need to remove the' Administrative Subdivision Type E55' and simply relate a mew authoirty file containing the governorates to the Administrative Subdivision.E48 node?

Thank you very much, Lucy

. 

[Carlisle, Philip]

Hi Lucy,

You would be breaking the rules if you used the Type for your list but the way you’ve suggested is fine. I’d add ‘Governate’ as your only Administrative_Subdivision_Type.E55 but then associate a new authority file to the E48. As E48 is a Place Name and these are usually subject to a gazetteer then a E48- P71- E32 triple is acceptable where E32 is your Governate authority file.

 

Phil

 

Phil Carlisle

Data Standards Supervisor

Data Standards Unit, Listing Group

Historic England

The Engine House

Fire Fly Avenue

Swindon

SN2 2EH

Tel: +44 (0)1793 414824

 

http://thesaurus.historicengland.org.uk/ 

http://www.heritagedata.org/blog/

You received this message because you are subscribed to the Google Groups "Arches Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to archesprojec...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

We are the public body that looks after England's historic environment. We champion historic places, helping people to understand, value and care for them, now and for the future. 
Sign up to our enewsletter to keep up to date with our latest news, advice and listings.

HistoricEngland.org.uk           Twitter: @HistoricEngland

This e-mail (and any attachments) is confidential and may contain personal views which are not the views of Historic England unless specifically stated. If you have received it in error, please delete it from your system and notify the sender immediately. Do not use, copy or disclose the information in any way nor act in reliance on it. Any information sent to Historic England may become publicly available.

[Lucinda Fletcher-Jones]

Hi Phil,

I thought I'd posted a reply to this last week but I cannot see it in this thread. Thank you very much for your helpful input. I have a few other questions for you on standards. 

1. Address node in Location, for a heritage resource: Understandably we have no street addresses for our Egyptian sites but we do have some map grid references which we need to input somewhere. I originally thought of using the external cross reference  node but as it is a location reference, it more properly belongs to the location data. Can we use the address node (E.45) for this purpose?

2. Also, we wish to use  'Setting types', Place Site Location (E.53) for environmental setting type of a site . e.g under lake Nasser!! I think this is correct usage?

3. We wish to add Dynasty and Ruler to our cultural period. Egyptology rarely uses real dates mostly date is defined by cultural period/dynasty/ruler. I wish to add the Dynasty as a new node related to cultural period (a subset?) and then relate the ruler to Dynasty. Is this correct? We have authority files for each. 

[Carlisle, Philip]

Hi Lucy,

I hope all is well in Egypt. Here’s my thoughts.

1.     Surely the grid references are being used to generate a geometry?  The E45. Address nodes should only be used for postal addresses.

2.     Setting types can be used as you say.

3.     Dynasty – this is fine. We use Victorian to specify the reign of Queen Victoria so there’s no reason why you can’t add the dynasties. Just make your vocabulary consistent and comprehensible. Maybe something like ‘Reign of Rameses II’ rather than just ‘Rameses II’

Phil

 

Phil Carlisle

Data Standards Supervisor

Data Standards Unit, Listing Group

Historic England

The Engine House

Fire Fly Avenue

Swindon

SN2 2EH

Tel: +44 (0)1793 414824

 

http://thesaurus.historicengland.org.uk/ 

http://www.heritagedata.org/blog/

 

[Carlisle, Philip]

Hi Lucy,

Thanks for the explanation. I think you need to ask the GIS specialists about this one.

 

Phil

 

Phil Carlisle

Data Standards Supervisor

Data Standards Unit, Listing Group

Historic England

The Engine House

Fire Fly Avenue

Swindon

SN2 2EH

Tel: +44 (0)1793 414824

 

http://thesaurus.historicengland.org.uk/ 

http://www.heritagedata.org/blog/

 

From: Lucy Fletcher-Jones [mailto:luc...@aucegypt.edu]
Sent: 01 December 2015 14:45
To: Carlisle, Philip
Subject: Re: [Arches] Re: Authority Files and Mandatory Input Fields

 

Hi Phil,

Thank you for your reply. 

The grid references we wish to enter are for 2 different surveys of Egypt: one that was done by Britain in the 1920s and one by a joint UK/US operation, an aerial survey, in the 1940s (JOG reference). Both are very important to Egyptologists for locating sites but both sets of surveyors, in their wisdom, decided to ignore normal latitude and longitude and instead they divided Egypt into grids, of about 2500sqkm in the latter case. So we have JOG references such as NG 36-06, NH 34-08. We could find the corresponding Lat/long for each corner of the grid but it would be time consuming and anyway the reference is what is commonly used and understood. Should we create a new node?

 

Lucy

Sent from my iPad

[Lucy FJ]

Hi Phil and all,

In the absence of any further enlightenment from a GIS specialist, we would like to add these two grid references as 2 new nodes to node: Place_Site Location.E53. I presume this is legitimate? 

I have tried putting them in the location description box but the search does not work if they are both in there. 

I expect, to do this in a GIS manner, we should include these surveys overlays and search using the location filter, by drawing a polygon over the grid in order to get a list of sites in the grid. But I do not see the overlays on the search view. I see that Adam Cox put in a grid reference using an overlay on his Cane River Project. What suggestions do you have Adam?

Thank you, 

Lucy

On Tuesday, December 1, 2015 at 5:16:37 PM UTC+2, Carlisle, Philip wrote:

Hi Lucy,

Thanks for the explanation. I think you need to ask the GIS specialists about this one.

...

[Adam Cox]

Hi Lucy,

When it comes to GIS in Arches, there are a few different levels that you should be aware of.

Regarding the PLSS overlays that I included in the Cane River project: this is completely superficial, meant only for visual reference, and having nothing to do with the resource coordinates themselves.  I did it by creating a Web Map Service using Geoserver (independent of Arches) and pulling it in on top.  There are other ways of creating an overlay like that, but, again, it has no bearing on your resources and cannot be used in the search bar.

As you have found, if you want to search by these grid references, the easiest way is to have them added to each resource as searchable attributes.  To this end you've been adding new nodes, which will require changes in the location.htm, location.js, and forms.py files to support the new nodes.

The most "GIS way" to deal with this issue could involve another type of overlay that Arches supports, which is described in this documentation: https://arches-hip.readthedocs.org/en/latest/loading-data/#optional-gis-layers-for-administrative-areas.  This is how, given a set of polygon areas, you can be sure that any new resource that is created within a given polygon will automatically receive the name of that polygon as an "administrative area".  With a bit of GIS expertise, plus editing the graphs, and extra editing on the forms and their javascript, you could conceivably create two GIS files, one for each grid system, and each with a one meter square for every grid square.  Then any new resource would receive, as attributes, the names of the grid squares (i.e. the coordinates) that it overlaps.  This approach would definitely require some advanced work, and would require you to start with the creation of two new nodes anyway...

Hope that's helpful.  I'm sorry I can't give you a quick, easy solution right here, but as I mentioned before, any changes to the graphs require supporting changes to the forms, which can quickly become an involved process.

Adam

On Wednesday, October 28, 2015 at 7:40:46 AM UTC-5, Lucy FJ wrote: