Cool Tools for Easy Rich Collections Descriptions - getExRif API
Australian National Data Service (ANDS)
A spotlight on the ANDS Developer Tool Box - getExtRif API The getExtRif API provides powerful access to the contents of the ANDS Collections Registry, much like the getRIFCS API. The important difference is that getExtRif includes an additional non-RIFCS element called -extRif:extendedMetadata-. During the processing of new records in the ANDS Registry, this element is populated with additional metadata about the record content and its context. This video gives a brief introduction to Extended RIF-CS (ExtRif) and the getExtRif API.
 Thanks everybody for turning up. Joel Ben here, business analyst in the services team. The XRIF API, again, it's another one which pulls information out of the registry. It's very similar to the GetRif CS API, but it differs in a way that it pulls back extended RIF. And the extended RIF is basically when records are ingested into the registry, we do some transformations and enriching to those records to, for example, when things come in with the ANZSRC FOR codes, which is the six digit codes, we actually convert them to the string literal and store that in the XRIF. Spatial lat longs and things like that coordinates, we actually convert them to a geometry that's compatible with Google Maps. And the connections themselves, when we get a key in the RIF CS and the relationship, we actually go and resolve that to a person's name. I think the status as well is vital. And also we store obviously information about when the record came in and out of the registry, which we can use later on in searches. And this information is obviously really useful for other people that don't necessarily completely understand what's in the RIF CS itself, so the data within the RIF CS. I mean, if you picked up a piece of RIF CS and you didn't quite know what ANZFOR was, you wouldn't know what that six digit was going to convert to. So the extent of RIF CS is going to be useful to some people. So again, just the address for research.at australia.ans.org.au for slash developers. The web services themselves, they're not as pretty because there's no real fancy front into them. There are little explanation diagrams for each, I think nearly all of the services that we have just showing sort of how they work. There's obviously the description and the use cases for each of the services, how people might want to implement them and the useful points about them. As you can see here before you start, the one thing to note about the services themselves is that any developer that wants to use them actually has to register for a API key that they pass when they call them the services. And that's just a way of us knowing and identifying who's actually using the services. You don't have to be a user with a log onto the registry. You can just click the link and it'll take you to a publicly accessible page where you fill out the organization, the contact email and why you want to basically use the API key. And you click register and it will basically right there and then generate your key to pass with the service calls. And a couple of example uses of working service calls. And that's pretty much all I've got.
 Thanks everybody for turning up.  Joel Ben here, business analyst in the services team.  The XRIF API, again, it's another one which pulls information out of the registry.  It's very similar to the GetRif CS API, but it differs in a way that it pulls back extended  RIF. And the extended RIF is basically when records are ingested into the registry,  we do some transformations and enriching to those records to, for example, when things come in with  the ANZSRC FOR codes, which is the six digit codes, we actually convert them to the string  literal and store that in the XRIF. Spatial lat longs and things like that coordinates,  we actually convert them to a geometry that's compatible with Google Maps.  And the connections themselves, when we get a key in the RIF CS and the relationship,  we actually go and resolve that to a person's name. I think the status as well is vital.  And also we store obviously information about when the record came in and out of the registry,  which we can use later on in searches. And this information is obviously really useful for other  people that don't necessarily completely understand what's in the RIF CS itself,  so the data within the RIF CS. I mean, if you picked up a piece of RIF CS and you didn't quite  know what ANZFOR was, you wouldn't know what that six digit was going to convert to.  So the extent of RIF CS is going to be useful to some people. So again, just the address  for research.at australia.ans.org.au for slash developers. The web services themselves,  they're not as pretty because there's no real fancy front into them. There are little explanation  diagrams for each, I think nearly all of the services that we have just showing sort of how  they work. There's obviously the description and the use cases for each of the services,  how people might want to implement them and the useful points about them. As you can see here  before you start, the one thing to note about the services themselves is that any developer that  wants to use them actually has to register for a API key that they pass when they call them  the services. And that's just a way of us knowing and identifying who's actually using the services.  You don't have to be a user with a log onto the registry. You can just click the link and it'll  take you to a publicly accessible page where you fill out the organization, the contact email and  why you want to basically use the API key. And you click register and it will basically  right there and then generate your key to pass with the service calls. And a couple of example  uses of working service calls. And that's pretty much all I've got.
getExRif_API_-_Cool_tools_in_the_developers_toolbox_uDIzYWSu3gg_3_0_2387.png getExRif_API_-_Cool_tools_in_the_developers_toolbox_uDIzYWSu3gg_3_2388_2735.png getExRif_API_-_Cool_tools_in_the_developers_toolbox_uDIzYWSu3gg_3_2736_3671.png getExRif_API_-_Cool_tools_in_the_developers_toolbox_uDIzYWSu3gg_3_3672_4088.png
Thanks everybody for turning up. Joel Ben here, business analyst in the services team. The XRIF API, again, it's another one which pulls information out of the registry. It's very similar to the GetRif CS API, but it differs in a way that it pulls back extended RIF. And the extended RIF is basically when records are ingested into the registry, we do some transformations and enriching to those records to, for example, when things come in with the ANZSRC FOR codes, which is the six digit codes, we actually convert them to the string literal and store that in the XRIF. Spatial lat longs and things like that coordinates, we actually convert them to a geometry that's compatible with Google Maps. And the connections themselves, when we get a key in the RIF CS and the relationship, we actually go and resolve that to a person's name. I think the status as well is vital. And also we store obviously information about when the record came in and out of the registry, which we can use later on in searches. And this information is obviously really useful for other people that don't necessarily completely understand what's in the RIF CS itself, so the data within the RIF CS. I mean, if you picked up a piece of RIF CS and you didn't quite know what ANZFOR was, you wouldn't know what that six digit was going to convert to. So the extent of RIF CS is going to be useful to some people. So again, just the address for research.at australia.ans.org.au for slash developers. The web services themselves, they're not as pretty because there's no real fancy front into them. There are little explanation diagrams for each, I think nearly all of the services that we have just showing sort of how they work. There's obviously the description and the use cases for each of the services, how people might want to implement them and the useful points about them. As you can see here before you start, the one thing to note about the services themselves is that any developer that wants to use them actually has to register for a API key that they pass when they call them the services. And that's just a way of us knowing and identifying who's actually using the services. You don't have to be a user with a log onto the registry. You can just click the link and it'll take you to a publicly accessible page where you fill out the organization, the contact email and why you want to basically use the API key. And you click register and it will basically right there and then generate your key to pass with the service calls. And a couple of example uses of working service calls. And that's pretty much all I've got.
business analyst in the services team. The XRIF API, again, it's another one which pulls transformations and enriching to those records them to a geometry that's compatible with Google store obviously information about when the record later on in searches. And this information is and the use cases for each of the services, how services themselves is that any developer that