Decide if we use named nodes, blank nodes or hash-URIs for schema:geo
ktk opened this issue · 4 comments
Currently it's a hash-URI that cannot be resolved by LINDAS SPARQL endpoint.
Related issue in carml: carml/carml#67
More Map-Fun. I've added WKT POINT as well so it's easier to use with YASGUI.
Problem: Didok is a place as well, we need to distinct them otherwise we get stations like Magglingen as well as in this example.
@ktk can you elaborate why a hash URI can't be resolved by LINDAS SPARQL endpoint? I looked quickly at your examples but didn't see a hash URI.
Hash URIs work fine in repositories and in SPARQL.
They only make a difference if you fetch an entity URL. Given a url like <foo#bar>, the client should send only <foo> to the server, so it only makes sense to use them if <#bar> is a properly owned sub-object of <foo>, and the LD server can return all triples of <foo> and all of its sub-objects. So the best practice is to use hash URIs only for ontologies, where typically the whole ontology is one file, and it's preferable to get it and all its terms in one go.
Nevertheless, re carml/carml#67 I strongly recommend against using blank nodes, but constructing appropriate URLs eg by using / as separator. Blank nodes are hard to follow and debug. Eg you can't fetch a blank node from an LD server (unless it's included in the CBD of its "parent" non-blank node, something recommended in response to DESCRIBE)
@VladimirAlexiev LINDAS currently does not provide a DESCRIBE handler that returns hash-URIs as well so if I use them, we will never see them with dereferencing. There would be one for blank nodes but it's not enabled right now AFAIK (I'm not maintaining the LINDAS endpoing).
I'm a big fan of blank nodes, especially if the contained information does not make sense outside of its own parent entity anyway. But I do see that we could simply create a separate object in here as well.