-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base IRI description in the spec #30
Comments
IMO we should explicitly say in the spec that the base IRI for the RDF triples is not the same as for the mapping language.
Will this enforce to provide a base IRI always in the execution of an engine? |
We have a proposal here for the RML-core. |
I agree this needs to be documented in the spec, as the existence of two relative URLs is a necessary part of the setup. I think there is a lightweight solution that should also be explained. If neither base url of the mapping document is given (via
|
In <#allDataMap> a rr:TriplesMap;
rr:subjectMap [
rdfs:seeAlso <https://github.com/kg-construct/rml-questions/discussions/25>;
rr:termType rr:BlankNode;
rr:template "node{ }";
rr:class sosa:Observation;
] . But the following gives URLs (when called with <#allDataMap> a rr:TriplesMap;
rr:subjectMap [
rdfs:seeAlso <https://github.com/kg-construct/rml-questions/discussions/25>;
rr:template "node{ }";
rr:class sosa:Observation;
] . Note though that the second is a subgraph of the first. An RDF Graph should imply all its subgraphs, yet here we have the removal of rr:BlankNode changing the output from one that produces blank nodes to one that produces URLs. In a way it should be the other way around as URLs require more information than blank nodes. But instead I would suggest using two different exclusive relations |
As far as I know there exists no relative URI without a base. So as per R2RML
A processor must have access to a base IRI. Usually if not provided, a processor implementation will have a default. |
R2RML defines default values
I would prefer not to go this route, as this would introduce more language as well as break backwards compatibility with R2RML and RML in its current form. |
I am just wondering if default meanings of relations makes for valid RDF. The RDF Semantics spec states that a graph implies its subgraphs. So one needs to clarify what is going on here. |
Agreed, this has to be clarified. |
A proposal for this has as follows:
The base IRI of the Triples Map is used in resolving relative IRIs produced by the R2RML mapping. such a base IRI would allow us then to write something along these lines:
for a CSV like the following: id | name and that would create the following triples:
If we want to go a step further, we could allow such a base IRI to be defined not only on Triples Map level but also on Term Map level. That should not be confused with the base IRI of the document.
the document's base will refer to the relative IRIs of the mapping document, so in this case it will be |
Question. The proposal above seems fine, but does that mean we eliminate the base IRI given as input (i.e., specified in the config file)? If yes, then we need to specify this (but we would need to declare that for at least every triples map). I would prefer to see the second as it would render the mapping less verbose, but then specify that each rml:baseIRI assertion overrides the previous one. |
I would say yes, better to have it in the mapping than in the config file
I would not see any problem on this |
is the description/definition of the base IRI sufficient as it comes from the R2RML spec or do we need to further clarify certain aspects of it?
The text was updated successfully, but these errors were encountered: