 So, yeah, I work at Griffith University in e-research services and a while ago we used the ANS Research Grant API to improve the data that we present in the Griffith University Research Hub. So the Research Hub is our publicly facing researcher profile system and we build that for two main purposes. One to make Griffith Research more discoverable to show what we are doing. And the other one to give researchers a profile that they can use for their own purposes that you know they can share that shows their work individually. And to give a bit of background the Research Hub is built using Vivo which is a semantic web application and it's becoming quite popular. There's a large number of universities worldwide that built their research profile systems based on this. It came from Cornell University originally so there's a huge uptake in the US in particular. As a semantic web application it has a couple of very nice benefits for this sort of purpose and one is that it provides a very rich ontology to model information about researchers, research related activities, organizations such as institutes, schools, groups and in terms of activities we can model publications, grants and other research output. And of course it's also easy to add a party or your own ontologies to add even more data to this. Now when we developed the Research Hub one of the main aspects that we wanted to cover was that people would not have to maintain their profiles themselves and so in that spirit we try to get as much data as possible from various enterprise systems at Griffith and external systems if available. And so at the end at the moment researchers really only have to add their photo if they want one a short biosay statement and maybe a research statement and everything else including academic degrees, employment history, publications, grants, supervision and so on gets drawn from enterprise systems and we get the same information about institutes, groups and schools. However one problem that we came across was that enterprise systems were at some point built for a specific purpose and that was usually not that the data would be displayed publicly. And for a lot of the data that's not a huge issue, publication records are fairly standardized so we didn't have any problems there but grant information in particular was not very well covered in our systems. Sometimes just because we weren't the managing organization so if things changed later on in terms of titles and amounts and whatnot that wasn't necessarily reflected in our systems and the other reason is that we didn't necessarily need descriptions and whatnot for the reporting purposes the systems were built for. So for the Research Hub we identified two business cases where we could use external grant data and really add some value to the Research Hub and one was to improve data on existing grants, get better descriptions, get full funding amounts like the total grant amount and not just the share that Griffith University got from it and the other business case was that while we knew about grants that at some affiliation with Griffith we didn't know anything about grants that researchers had while they were not at Griffith University and so adding that information became quite important because while it doesn't showcase any Griffith research it is an important part in the biography of our researchers and it gives a much more complete picture especially because we do have historic information about publications and whatnot so not having the grants left a gap that that many people were sort of eager to close and again we didn't want people to enter this information manually so getting as much of that done automatically as possible was the end goal and this is where the ANS Research Grant API came in and yes that in the previous talks it draws from the same data sources as the Research Data Australia portal and so it has very comprehensive information especially about ASC and NHMRC grants and it also provides us with a very nicely cleaned up version of this grant information so information that is maybe not well captured in a standardized vocabulary and the source data was actually cleaned up and is now provided in a very nice form and the API is based on solar which is a very simple to use very nice and very well documented enterprise search engine and so using this data was actually quite easy for us so for the first business case we didn't actually have to do very much we could basically look up grants based on their grant ID and the funding body grant ID is not necessarily unique across funding bodies but doing this lookup was quite easy and so we would get back the record as a JSON formatted record and all we really had to do was map those fields to our RDF vocabulary and do a few related lookups for people in our database and whatnot to to link it up properly but all in all it was a very very easy process and well we did this work quite a while ago so about a year and a half I think most of it and initially a lot of the text fields still contained a lot of the actual information in terms of funding amounts and whatnot and we did a fair bit of text processing to extract it as well nowadays and has done a lot of work on improving this and so we're now getting a much cleaner version of the data so whoever wants to get into this area now and use this information is in a really good position to get very nice and clean data from this. The second business case was a lot more difficult so we just heard about research identifiers it's still very difficult to get that information for our researchers at the moment and ORCID is not very common yet and we don't get ORCID identifiers from the API or from the funding bodies so what we have to do to get historic grants for researchers that had nothing to do with Griffith was we had to come up with a way of matching researchers by name and for that we built a two-stage scoring function one simply looked at name similarity and gave us some idea whether two names could be referring to the same person and we put a lot of empirical work into that because sometimes people go by a preferred name sometimes by the actual first name some people always include their middle name some people don't so it's a lot of work to do about that and then we still have the problem or had the problem that names are not unique and so we added a second score that was based on the fields of research people published in and we have very good information about that in the research hub so we could build a portfolio of four codes that people had published in previously and we just went by the assumption that if they had a grant in the past that had a certain four code that they would have at least one publication that had that four code as well yeah then we had to implement some additional handling for edge cases where grants were actually managed by Griffith and we had information about them but people were different institutions and still attached to them and linking all that up but that was all relatively easy once we had the linking up and running well I can't actually give any numbers about how well we are doing empirically it worked quite well and in practice over the last one and a half years I think we had about two or three false positives where people informed us that the data was incorrect and we built in functionality to manually add and remove grants but still automatically ingest the data and yeah so both of these cases were very successful and that was largely thanks to how easy the ANTS API was for us to access and to use and yeah I thought to wrap it up I quickly put up some links to the systems involved the first one is our research hub the second one for those who are interested and you may not know about it already that's the Vivo project which is definitely worth a look for everyone who's interested in getting into the space of researcher profile systems and the last one is the documentation to the ANTS API and as it's since it's based on solar there's a lot of additional resources everywhere on the web and yeah that's all from me