I have a CSV file with a few columns containing fully-qualified URIs for entities that are already in my graph. I have been able to import a virtual graph, but it seems like the URI columns are being treated as if they contain plain strings.
I'm using the first generation SMS. I could theoretically strip out "http.*/" form each URI, but I don't think I can do a mapping like below because the URIs in a given column don't all come from the same namespace.
Thanks, Paul. I'll have some time to revisit this later this week. Maybe I made a mistake or missed a feature... do you know if the SMS is documented thoroughly anywhere?
Using one of the other syntaxes or staging the data in a RDBMS aren't off the table, either.
The Stardog Mapping Syntax (SMS) is fairly simple. It's just turtle with templates. The documentation is here. Let us know if you notice something missing.
...or if you're super curious or looking for a more formal description you can always look at the parser in the stardog-union millan repo that powers the stardog studio language server protocol at millan/src/sms at master · stardog-union/millan · GitHub
stardog data export -f PRETTY_TURTLE -s -v mixedupdrugs_noquote
Exported 9 statements from mixedupdrugs_noquote to /home/ubuntu/.exports/mixedupdrugs_noquote-2019-04-21.ttl in 1.451 ms
I can confirm that using <{term}> always creates IRIs of form <urn:/http%3A%2F%2Fpurl.obolibrary.org%2Fobo%2FCHEBI_35480>
and it doesn't mater whether it is in subject or object position.
The even smaller example mapping shows this behaviour:
We have confirmed that this is an issue with our client-side CSV parsing and are working on a fix.
In the meantime, there are a couple of options to work around this:
Import the CSV into an RDBMS and then use the mappings to virtual import from that table. This work is performed server-side where this issue does not exist.
Use Excel formulas in the CSV to generate valid RDF and add it manually