I’m looking at data storage for GNOME Recipes and I was wanting to use Tracker 3 and not the current use of text files. My user story would be: A chef should be able to make their recipes available for other applications and share on the semantic web.
Schema .org provides turtle definitions but I’ll just want some of the turtles related to Recipes. Could I just import the whole document and start making updates and queries to tracker_sparql?
The document does not use xsd base types, would that be an issue? I won’t start on the code to connect to Tracker 3 any time soon, I just want to make sure I have a viable target to aim for.
Also, the app comes with a few default recipes that are translated, how does SPARQL work with translated information?
Yes, that may require some adaptions. It might suffice to make the basic types there subclasses of the xsd ones. The reliance on XSD is currently somewhat strong, and tracker does provide other facilities at defining ontologies. There is some documentation in the API docs that might help you in the porting process.
We are actively looking to improve this out of the box experience, although the goal of bootstrapping ontologies may be a distant one still. Don’t hesitate to ask questions or share your experience here or at the tracker IRC channel :).
As part of SPARQL 1.1, there is support for rdf:langString (e.g. "hello"@en), as well as LANG/LANGMATCHES/STRLANG builtin functions. In our implementation, rdf:langString and xsd:string are pretty much interchangeable.
Indeed. Having tried a few times to import ontologies, my opinion is Tracker’s core should stay as simple as it can, and we should provide scripts that convert ontologies from elsewhere into a format Tracker SPARQL can deal with.
In the case of schema.org, we can and should add a script to load the upstream TTL file, strip it down if needed, and add in the various properties that Tracker needs to set up SQLite appropriately.
The main difference is the ‘open world’ mindset of web ontologies like schema.org – where it’s important to include as much data as possible, even if it doesn’t strictly follow the standards – vs. the ‘closed world’ mindset of Tracker where we need to process the data as efficiently as possible. Hence why schema.org has ‘type hints’ like :rangeIncludes :Text, which we need to turn into type guarantees like rdfs:range xsd:string.
They also focus on XML and related formats that are text files, so they have no need for concrete data types. Their recipe examples just have a text filed for the author, but the docs says it can also link to an Organisation or Person class.
I’ll create an ontology that’ll hopefully be an equivalent subgraph of theirs so exporting and importing is easier.
Great, I don’t think the translation software is designed to process database language fields, so it might be best for me to keep the default recipes in a text file and on first boot the app can load the data and translations into SPARQL.
That is a very nice usecase.