search

NationalMuseumAustralia / Collection-API

The public web API of the National Museum of Australia
11 stars 0 forks source link

Internal API to include additional locations #77

Closed f27wood closed 6 years ago

f27wood commented 6 years ago

It does not look like the additional locations have been included in the internal API records.

From doco (API Filters):

For public API If LocLevel1=Acton, then also include: LocLevel2 (Gallery name to be converted to full name as outlined in API extra data doc)

For internal API, include the above plus all other location levels, being: LocLevel3 LocLevel4 LocLevel5 LocLevel6 LocLevel7 LocLevel8

f27wood commented 6 years ago

Note that public API is to use DisplayGallery instead of LocLevel1 and LocLevel2. See https://github.com/NationalMuseumAustralia/Collection-API/issues/79

I think the internal APi should have the DisplayGallery plus all of the locations including level 1 and 2, so we can search just for "Acton" to find all objects on display. And we may wish to add other level1 locations down the track to the internal api only.

staplegun commented 6 years ago

864 object records have LocLevel6 - all are Acton, there are none with LocLevel7 or LocLevel8 16529 55313 64549

f27wood commented 6 years ago

What do you mean by "all are Acton"? As only level 1 should be Acton...

Location levels for example records should be as as follows.

16529 Acton - Open coll. - Row 01 - Case 03 - Cab 01 - Shelf 04

55313 Acton - Open coll. - Row 01 - Case 02 - Cab 01 - Shelf 02

64549 Acton - GFA - Upper GFA - Communities - Lockhart River - Mission

staplegun commented 6 years ago

Looking at how to model the gallery location levels in CRM...

Need to use level numbers (as they don't consistently map on to semantic names, e.g. gallery, case).

Unfortunately there isn't an identifier for each gallery location, so propose to add a fragment off the object IRI representing "where this is on display" (assuming only one location), e.g. https://data.nma.gov.au/object/108547#exhibit This means multiple identifiers for essentially the same gallery.

1. Flat with CRM Place

<crm:P16i_was_used_for>
    <crm:E7_Activity rdf:about="https://data.nma.gov.au/object/108547#exhibit">
        <rdfs:label>Landmarks: People and Places across Australia gallery</rdfs:label>
        <!-- AAT 300054766: exhibitions (events) -->
        <crm:P2_has_type rdf:resource="http://vocab.getty.edu/aat/300054766" />
        <crm:P7_took_place_at>
            <crm:E53_Place rdf:about="https://data.nma.gov.au/object/108547#gallerylocationlevel1">
                <rdfs:label>Acton</rdfs:label>
            </crm:E53_Place>
        </crm:P7_took_place_at>
        <crm:P7_took_place_at>
            <crm:E53_Place rdf:about="https://data.nma.gov.au/object/108547#gallerylocationlevel2">
                <rdfs:label>Landmarks</rdfs:label>
            </crm:E53_Place>
        </crm:P7_took_place_at>
        <crm:P7_took_place_at>
            <crm:E53_Place rdf:about="https://data.nma.gov.au/object/108547#gallerylocationlevel3">
                <rdfs:label>Flemington</rdfs:label>
            </crm:E53_Place>
        </crm:P7_took_place_at>
    </crm:E7_Activity>
</crm:P16i_was_used_for>

2. Flat with NMA place class

<crm:P16i_was_used_for>
    <crm:E7_Activity rdf:about="https://data.nma.gov.au/object/108547#exhibit">
        <rdfs:label>Landmarks: People and Places across Australia gallery</rdfs:label>
        <crm:P2_has_type rdf:resource="http://vocab.getty.edu/aat/300054766" />
        <crm:P7_took_place_at>
            <nma:locationLevel1>
                <rdfs:label>Acton</rdfs:label>
            </nma:locationLevel1>
        </crm:P7_took_place_at>
        <crm:P7_took_place_at>
            <nma:locationLevel2>
                <rdfs:label>Landmarks</rdfs:label>
            </nma:locationLevel2>
        </crm:P7_took_place_at>
        <crm:P7_took_place_at>
            <nma:locationLevel3>
                <rdfs:label>Flemington</rdfs:label>
            </nma:locationLevel3>
        </crm:P7_took_place_at>
    </crm:E7_Activity>
</crm:P16i_was_used_for>

3. Nested

<crm:P16i_was_used_for>
    <crm:E7_Activity rdf:about="https://data.nma.gov.au/object/108547#exhibit">
        <rdfs:label>Landmarks: People and Places across Australia gallery</rdfs:label>
        <crm:P2_has_type rdf:resource="http://vocab.getty.edu/aat/300054766" />
        <crm:P7_took_place_at>
            <nma:locationLevel1>
                <rdfs:label>Acton</rdfs:label>
                <crm:P89i_contains>
                    <nma:locationLevel2>
                        <rdfs:label>Landmarks</rdfs:label>
                        <crm:P89i_contains>
                            <nma:locationLevel3>
                                <rdfs:label>Flemington</rdfs:label>
                            </nma:locationLevel3>
                        </crm:P89i_contains>
                    </nma:locationLevel2>
                </crm:P89i_contains>
            </nma:locationLevel1>
        </crm:P7_took_place_at>
    </crm:E7_Activity>
</crm:P16i_was_used_for>
Conal-Tuohy commented 6 years ago

I have a lot of questions about this:

f27wood commented 6 years ago

How are the locations actually modeled in EMu?

Each location level has a separate field entry which is a lookup table. i.e. a controlled list of options to select from. You need to select the location levels in order from 1 to 8, as the options available at each level depends on what was previously selected. Not sure if that answered your question?

What are the constraints on the data that can be entered?

As above - a controlled list of options to select from based on the previous location selected.

I assume the locations must be chosen from a list, and that there's a distinct list of possible locations for each "level"?

Correct

Do the different values in the list (e.g. Flemington) also have identifiers which could be exposed in the exported XML?

Not sure, I don't think so but not sure of the question. lets discuss on Thursday

Is it the case that if you enter e.g. Acton at level 1, and Landmarks at level 2, does that give you a list in which Flemington would appear, whereas if you put something different at level 1 and 2 you would not get the option of Flemington in level 3?

Correct

Or are they independent, i.e. without any co-occurrence constraints between the different levels (i.e. the option lists for a given level are always the same regardless of what you've selected for other levels).

as above

Conal-Tuohy commented 6 years ago

@SimmoK can you comment on the possibility of getting persistent identifiers for the individual locations (at every level) in the EMu XML export?

The identifier could be embedded in each record (alongside each of the existing locations' labels, as separate fields location5_identifier or something), or in a separate file of "locations.xml" as we did with sites.

SimmoK commented 6 years ago

What if i give you the EMu IRN of the Location record as a child of tag so a field above ? But i don't know if i can do and test before next week.

locexample

f27wood commented 6 years ago

BTW there isn't a unique identifier for every local level value. The irn is for the group of locations and in affect is an identifier for the location level.

In the example, the irn would be the unique identifier for any record with the exact same location levels. i.e. Acton - GFA - TSI - Pearling

f27wood commented 6 years ago

As discussed, adding some user case scenarios to assist us in resolving this.

Task1 - Find the exhibition and module location of an object Display an object showing the exhibition and module location.

Example one Object: 231572 Horseshoe worn by Rising Fast, 1954 Location info: Acton – Landmarks – Flemington Racecourse – Case 01 Where LocationLevel3 "Flemington Racecourse" is the module.

Example two Object: 5295 Firedrill base Location info: Acton - GFA - Level 2 - Fire Wall Where LocationLevel4 "Fire Wall" is the module

Question about this one - how do we (and is it even possible) automate this in so far as being able to create a template to show the module location of an object, using the API, but somehow coding in what module level is required for each combination of location levels.... it would require some coding but possible I think. Or in the future, we can have a way of indicating this in the data. This is where having an id for each location would be good as the id could state if it is a gallery, module or showcase and what the label should be. Or maybe it is best to use the show case or the last location level, as these will have an IRN and be the exact location of the object, and has a description field in EMu we could use (not currently populated).

Task 2 - Find the showcase in which an object is located May be used in a way finding app, to take the user to the case in which the object is located.

Example one Object: 50474 Plaque presented by the Government of NSW to commemorate the official opening of the Sydney Opera House in 1973 Location info: Acton - Landmarks - Bennelong Point - Case 01

Example two Object: 233288 Example of a seat designed for the Sydney Opera House by Earl Owen Location info: Acton - Landmarks - Bennelong Point - Case 02

Task 3 - List objects in a particular gallery module Could be used on the modules page of Landmarks, auto linking to objects from each module http://www.nma.gov.au/exhibitions/landmarks/about_landmarks/urban_life Or could be used in a way finding or tour app to identify all of the objects within a given module.

Example List all of the objects in the Bennelong Point module of Landmarks, noting that there are two showcases in this module. Location info: Acton - Landmarks - Bennelong Point - Case 01 Acton - Landmarks - Bennelong Point - Case 02

Task 4 - List objects in a particular show case Could be used in a way finding or tour app to identify all of the objects within a given case.

Example: List all of the objects in the Bennelong Point module, showcase two. Location info: Acton - Landmarks - Bennelong Point - Case 02

f27wood commented 6 years ago

BTW I don;t think we are going to be able to implement this perfectly as the location level meanings are not consistent. However if we know the issues, we can work on improving this.

SimmoK commented 6 years ago

Hi @Conal-Tuohy . Can you confirm that adding Location IRN as in comment https://github.com/NationalMuseumAustralia/Collection-API/issues/77#issuecomment-413442356 is required?

SImon

Conal-Tuohy commented 6 years ago

Hi @SimmoK -- I've talked this over with @f27wood this morning and I think I understand the point that only the most specific locations have an irn, now. I will need to study this issue further, and I think some additional discussion may be needed, too. To be honest at the moment I'm not sure if the location's irn will actually help to support the use cases listed above, though certainly it couldn't hurt to have it available.

I'm not sure how we can support the first example use case; I don't see how we can tell which location level denotes a "module".

The second example (referring to the showcase) is easier. Is the showcase just the most specific location for a given object? Or are there locations which are the most specific but which are not "showcases"? i.e. an object being located no more specifically than as just being in a particular gallery?

The third and fourth examples (listing the objects in a location, which may or may not which have sub-locations) are easy, I think.

My concern is to model the information in a simple way that doesn't distort the underlying facts, but which doesn't necessarily capture them in their full complexity if that's not required.

SimmoK commented 6 years ago

Cool I'll add it. Yes you are correct Task 1 and Task 2 aren't possible due to the variable nature of the data and structure of the locations hierarchy. Task 3 and 4 should be achievable.

f27wood commented 6 years ago

Task 1 - agreed this is not possible to automate for all objects, but think it may be possible for API users to use more complex code to do something like: Check locationLevel2, if it equals GFA, then show LocationLevel4 as the module, if it equals Landamrks, show location 3 as module. Certainly not ideal but possible if we really needed to.

Task 2 - only possible with complex coding as above, although if we were to create a way finding app, the app could map each of the locations to a geocode and label. i.e. Acton - Landmarks - Bennelong Point - Case 01 Would have a geocode and a label such as: Located in Landamarks, Bennelong Point module, case on the left If it also uses the irn from EMu for that location string, we could potentially then export these as xml so the APi could use this info too!

Task 3 and 4 - yes should be easy as you are starting with the location value rather than the object.

Conal-Tuohy commented 6 years ago

@f27wood you are saying that if an API client has knowledge (independently of the API itself) of the nature of various levels of the location hierarchy (i.e. that this one is a showcase, while that one is a module, etc.) then they can combine that knowledge with the API to form the queries they need?

That's certainly true, though from a user's perspective it's simpler if the information they need is all in the API. One way to deal with this would be to define the entire hierarchy of locations in a separate RDF graph e.g. locations.rdf and make the ETL add that graph to the triple store. We already do something similar where we list "terms" (used for classifying things in the API such as "thumbnail" images). This would mean maintaining the locations independently, with identifiers and labels, and types ("module", "showcase", "gallery", etc) and parent/child relationships, but it would allow for the API to include links from a location to "parent" and "child" locations.

f27wood commented 6 years ago

Yes to your first question

And yes I agree it would be preferable to have the info in the API as a locations rdf. That seems a bit tricky to do though?? So maybe out of scope for now, but something to look at for phase two.

f27wood commented 6 years ago

From our last conversation, I think the next step was for you Conal to think about how easy/hard it would be to create a locations.rdf. Was that right?

The main thing to note is that the locations will change at times, such as:

Mostly, we will know about new locations as they will be part of a new exhibition development. The change overs are likely to be the ones we may miss as these are more ad hoc. However, the level 1 and level 2 locations are likely to stay the same in these instances.

f27wood commented 6 years ago

This is the list of locations from EMu Locations Summary Data.docx

f27wood commented 6 years ago

Tested on NMA Test and passed.

f27wood commented 6 years ago

tested and passed in prod.