Forward slashes in resource name

[elad-shaked]

I encountered the following IRI in links_domain=yago_lang=en.nt:
<http://dbpedia.org/resource/Cannone_da_75/27_modello_11>
And this one in mappingbased-objects_lang=en.ttl:
<http://yago-knowledge.org/resource/Cannone_da_75/27_modello_11>

The actual page is this: https://en.wikipedia.org/wiki/Cannone_da_75/27_modello_11
Obviously, the forward slash in “75/27” should be encoded (even though Wikipedia does not encode it).

[kurzum]

@elad-shaked we created rules to test this:
https://github.com/dbpedia/extraction-framework/blob/master/dump/src/test/resources/dbpedia-specific-ci-tests.ttl#L150
There is currently no rule for / since it should be allowed. Is there any reason, why this should be encoded? We normally follow Wikipedia.
Links:

• https://svn.aksw.org/papers/2020/semantics_marvin/public.pdf
• http://dev.dbpedia.org/Improve_DBpedia

Our todo here however is to run the tests on https://databus.dbpedia.org/dbpedia/transition/links/ which we don't at the moment.

[elad-shaked]

@kurzum / is allowed as delimiter creating sub-namespaces. This makes sense, but is not the case in this issue's examples.

[kurzum]

Technically, / is a defined char in the hierarchical path. There is no such thing as sub-namespaces in URIs/IRIs. There is a trade-off here:

1. XML and Turtle prefixes won't work well with /
2. replace ("wikipedia.org","dbpedia.org") will not work any more
3. RDF requires to be exactly the same. So if we change it, then the RDF will break somewhere down the line.

The / is fine per se as you can use any valid URI in RDF and we chose to use the same as Wikipedia.
@elad-shaked I am wondering though what exactly your technical problem is. Is there a technical interoperability problem?

[elad-shaked]

Thank you for the clear breakdown - it helps a lot.
My technical problem was using RDF4J's IRI.getNameapace(). Now that I better understand the tradeoff I have no technical problem with DBPedia.
Closing this issue (feel free to re-open)

[kurzum]

I reopened it, there are todos left:

1. we should track how many URIs are affected.
2. Some of the things here belong in the documentation