Comments (10)
I vote for consistency, i.e., allow constant blank nodes!
from rml-core.
I agree that that problem remains regardless, but I should have clarified I was talking about the POV of the constant blank node from the mapping. IMHO, I fear the use of constant blank nodes (not simulated constants in templates) is therefore potentially confusing and not that useful. I think I understand why the R2RML spec has not allowed this
Here's an example that would make things complicated and confusing: rr:constant [ ex:foo ex:bar ];
Do we include only the blank node in the output? The blank node and all its properties? If yes, then that's a copy and how deep should the copies go? Deep copies are to be avoided, as that would give a bespoke meaning and behavior for rr:constant with blank nodes. If one wants to generate blank nodes with properties, it would make more sense to use a template and then have another triples map using that same template for generating information about that blank node.
In short: ff we would allow blank node constants: then we should state the motivation for it was to streamline everything but put a little disclaimer stating that the output is (likely) not that useful. We should then also state that only the blank node is "copied". We can even include an example in an appendix. If we were not to allow blank node constants, then a little paragraph explaining why would be welcome as to avoid questions in the future.
from rml-core.
I agree that that problem remains regardless, [...]
I wouldn't call it a problem per se. But it is good to make a note of the effect of using blank nodes across graphs.
[...] but I should have clarified I was talking about the POV of the constant blank node from the mapping. IMHO, I fear the use of constant blank nodes (not simulated constants in templates) is therefore potentially confusing and not that useful. I think I understand why the R2RML spec has not allowed this
Agreed.
Here's an example that would make things complicated and confusing:
rr:constant [ ex:foo ex:bar ];
Do we include only the blank node in the output? The blank node and all its properties? If yes, then that's a copy and how deep should the copies go? Deep copies are to be avoided, as that would give a bespoke meaning and behavior for rr:constant with blank nodes. If one wants to generate blank nodes with properties, it would make more sense to use a template and then have another triples map using that same template for generating information about that blank node.
+1
In short: ff we would allow blank node constants: then we should state the motivation for it was to streamline everything but put a little disclaimer stating that the output is (likely) not that useful. We should then also state that only the blank node is "copied". We can even include an example in an appendix. If we were not to allow blank node constants, then a little paragraph explaining why would be welcome as to avoid questions in the future.
I think given this discussion I would opt for leaving it as was defined in R2RML, so not allowing blank node constants, but still add a note explaining the rationale, and possibly also a note on generating blank nodes in multiple graphs with the same mapping construct.
from rml-core.
Given this, fully agree on not supporting blank node constants and including a note (clearly this note is needed for short-sighted readers like me!) :D
from rml-core.
We should get rid of this limitation and allow constants for blank nodes as it streamlines everything. While very specific, I can foresee a case where you can use this to provide metadata of something captured in a blank node.
from rml-core.
I was going to vote for the same (see my previous comment), but there is a catch. Blank nodes (and their blank node identifiers) only hold within the scope of their document. _:b1 in the mapping and _:b1 in the resulting RDF document are not the same.
Then there's also the problem of named graphs. Blank nodes with the same identifier in different named graphs do not refer to the same entity. If we use a blank node as a constant and it appears in different graphs in the output, they are basically different blank nodes.
This only works if the base IRIs of both mapping and output are the same. R2RML does not assume this. Some RML implementations do (using the base of the mapping as the base of the output). R2RML uses a base of mapping and explicitly states that the base IRI of the output is an argument to be passed to the processor. We could state that the blank node we use as a constant will be "copied" into the output (deep copy? shallow copy? what about blank nodes that refer to blank nodes)? But that could potentially be confusing for those familiar with RDF and not with mapping languages.
In short, I believe I now understand why it wasn't supported because blank node identifiers in different documents do not refer to the same thing.
from rml-core.
But, those problems are no different for blank nodes that are generated using rr:template
(or blank nodes in general for that matter), or am I missing something? In essence [ rr:template "_:b1", rr:termType rr:BlankNode ]
(which is allowed) is the same as [ rr:constant _:b1 ]
, no?
EDIT: I would in general advice against using blank nodes (for the reasons you mention above), but not put this (arbitrary?) limitation that can be circumvented in the spec
from rml-core.
@chrdebru thanks. This point is key indeed:
_:b1 in the mapping and _:b1 in the resulting RDF document are not the same.
I hadn't considered this (🤦🏼♂️). I know there are some RDF libraries that can store the blank node identifier and reuse it, like RDF4J , but this cannot be expected of all RDF parsing implementations.
But, those problems are no different for blank nodes that are generated using rr:template (or blank nodes in general for that matter), or am I missing something? In essence [ rr:template "_:b1", rr:termType rr:BlankNode ] (which is allowed) is the same as [ rr:constant _:b1 ], no?
It would then be [ rr:template "b1", rr:termType rr:BlankNode ]
by which the template provides the bnode id string b1
which, unlike the id of an RDF blanknode, can be stably reused.
Then there's also the problem of named graphs. Blank nodes with the same identifier in different named graphs do not refer to the same entity. If we use a blank node as a constant and it appears in different graphs in the output, they are basically different blank nodes.
Agree with @bjdmeest, this ability will remain regardless.
from rml-core.
But, those problems are no different for blank nodes that are generated using
rr:template
(or blank nodes in general for that matter), or am I missing something? In essence[ rr:template "_:b1", rr:termType rr:BlankNode ]
(which is allowed) is the same as[ rr:constant _:b1 ]
, no?
There is a difference; templates are functions that return identifiers--even if they contain no references and are therefore constant. Those identifiers are themselves not used in the original document.
If you say rr:constant _:b1
, then that _:b1 is declared in the mapping. You can write _:b1 ex:foo ex:bar
in the mapping and that blank node has properties. With a template, however, things are different. [ rr:template "_:b1", rr:termType rr:BlankNode ]
does not declare the existence of _:b1 in the mapping. The term map will generate a blank node with that identifier for the output.
from rml-core.
There's an agreement, note is in the spec, closing.
from rml-core.
Related Issues (20)
- Issues with MySQL test cases HOT 10
- RFC: RMLTC0002c-JSON & RMLTC0002c-XML (bis) HOT 2
- Error in spec about referencing attributes when processing XML HOT 1
- Issues with XML test cases HOT 8
- Missing test cases for multi-valued reference maps HOT 4
- Inconsistencies, errors, ... in SHACL shapes
- OM, SM, and GM may have no reference, template, or constant HOT 6
- Implementation notes HOT 18
- Should DatatypeMap be defined as a TermMap? HOT 3
- Result of expressions should be an array/list instead of set
- Use RFC 9535 JSONPath compliant query expressions in spec and test cases
- Define ill-formed joins in the spec HOT 4
- capture a piece of JSON/XML as a literal HOT 2
- Define Logical Source in RML-Core instead of RML-IO HOT 1
- Miss-Alignment between the shapes in https://kg-construct.github.io/rml-core/ontology/rml-core-bc.ttl and R2RML specification HOT 4
- There is no notion of order in RDF mappings, and this has implications for the RDF output HOT 2
- How to construct graph object HOT 2
- Replace `sh:name` and `sh:description` in SHACL shapes HOT 2
- Issue in test case 10b-JSON HOT 3
- Enhance validation and generation error description in the spec HOT 8
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.