Comments (11)
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.
My proposal will redefine the base IRI definition as:
- The base IRI should be provided in the config file or CLI of the engine
- The base IRI of the mapping document refers to the actual rules
Will this enforce to provide a base IRI always in the execution of an engine?
from rml-core.
A proposal for this has as follows:
<#TriplesMap>
rml:baseIri "http://example.com/" .
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:
<#TriplesMap>
rml:baseIri "http://example.com/" .
rml:subjectMap [
rml:template "{id}";
rml:class :Person ].
for a CSV like the following:
id | name
1 | Bob
and that would create the following triples:
<http://example.com/1> a :Person.
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.
@base <http://mygraph.org/> .
<TriplesMap>
rml:baseIri "http://example.com/" .
rml:subjectMap [
rml:template "{id}";
rml:class :Person ].
the document's base will refer to the relative IRIs of the mapping document, so in this case it will be <http://mygraph.org/TriplesMap>
.
from rml-core.
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)?
I would say yes, better to have it in the mapping than 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 not see any problem on this
from rml-core.
We have a proposal here for the RML-core.
from 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 @base
or command line argument) then
- the relative URL of the document (should just be file:// if found on the file system, or take from the location of the document on the web) -- this is usual Relative URL interpretation, but programmers may not be aware of this.
If the relative url of the output is not given by command line argument (or specified in some way by ontology extension) then the mapper should - produce output (which should just be a relative url if the -b attribute is not specified
from rml-core.
In rmlmapper-java
I noticed that the following gives blank nodes
<#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 -b <url>
command line argument, otherwise it gives a blank node)
<#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 rr:template
and rr:blankNodeTemplate
perhaps.
from rml-core.
produce output (which should just be a relative url if the -b attribute is not specified
As far as I know there exists no relative URI without a base. So as per R2RML
An R2RML processor also has access to an execution environment consisting of:
- A SQL connection to the input database,
- a base IRI used in resolving relative IRIs produced by the R2RML mapping.
A processor must have access to a base IRI. Usually if not provided, a processor implementation will have a default.
from rml-core.
In
rmlmapper-java
I noticed that the following gives blank nodes<#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
-b <url>
command line argument, otherwise it gives a blank node)<#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.
R2RML defines default values rr:termType
depending on the type of term map.
So the term type is actually implied when not specified.
But instead I would suggest using two different exclusive relations
rr:template
andrr:blankNodeTemplate
perhaps.
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.
from rml-core.
R2RML defines default values rr:termType depending on the type of term map. So the term type is actually implied when not specified.
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.
from rml-core.
Agreed, this has to be clarified.
from rml-core.
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).
If no, then we need to specify the behavior of a input base IRI and the ones declared at triples map, and term map levels. We might end up with something complicated as the graph map declarations on subject map and predicate-object map level.
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.
from rml-core.
Related Issues (20)
- parent and child terminology HOT 5
- Testcases: port from RML testcases
- Some bad hyperlinks in the spec HOT 3
- Data error handling (e.g., lenient mode)
- Separate sections for ExpressionMap and TermMaps in spec
- Extending usage of GraphMap at PredicateMap and ObjectMap level HOT 2
- rr:template: also provide an URI-unsafe alternative? HOT 1
- Ontology: rdfs:isDefinedBy using incorrect ontology IRI HOT 1
- Join specification when logical source is the same HOT 11
- Mistakes in the shapes HOT 6
- Joins in RML HOT 25
- Validity of template HOT 1
- The RML namespaces do not dereference HOT 6
- What about referencing object/term maps HOT 2
- Issues in test cases HOT 7
- Defining window operations in RML HOT 4
- Details lacking in datatype map HOT 1
- RML-Core test cases are too dependent on RML-IO HOT 3
- Bugs in shacl shapes HOT 2
- Section 6.6.1 Automatically deriving datatypes is underspecified HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rml-core.