Semantic unit conversion app using Sentier.dev platform #1
Description
Overview
We have a database with units, code for a specific type of unit conversion, and the need for a general API for converting units in the future.
User stories
Let's build a webapp that can do the following:
- Given a unit string, tell me what the preferred term and URI for that unit concept are in other systems
- Given a unit concept URI, give me all known units in the same quantity type for a given unit system including conversion factors
- Given a unit string which doesn't match a preferred term exactly, give me search results for that term which includes descriptions and alternative terms from all systems
And finally, tie all this together so you can start typing a unit, pick the right one from a dropdown, and then get tables of conversion factors for each system we include.
Unit systems
The unit systems we already have:
- SimaPro
- ecoinvent (only URIs, need to include other data for search unless we want to query their API as well)
- QUDT
Unit systems I would like to have:
- FedEFL / lcacommons.gov
- OpenLCA
Tasks
- Pick architecture for frontend and backend
- Build an API backend which can support the user stories and draws data from our Fuseki database
- Deploy the API
- Design the frontend
- Implement the frontend
- Add missing unit systems
- Fix search on skosmos and expose API
- Implement varnish cache on skosmos deployment
- Have correct skosmos deployed on our cloud architecture
Stretch goals:
- Build a client library on top of the API
Skosmos search
This is possibly hard. We have a search index via skosmos (which should also have an API), but it only searches on prefLabel (see search result for btu versus british), and maybe on altLabel. We are currently using notation ("Notations are symbols which are not normally recognizable as words or sequences of words in any natural language and are thus usable independently of natural-language contexts"), but we could change these to altLabel, or add altLabel in addition to notation (there are strings, even if they have custom data types, so should be fine for being instances of RDF plain literal).