Giter Club home page Giter Club logo

Comments (10)

bjdmeest avatar bjdmeest commented on September 27, 2024 1

I vote for consistency, i.e., allow constant blank nodes!

from rml-core.

chrdebru avatar chrdebru commented on September 27, 2024 1

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.

pmaria avatar pmaria commented on September 27, 2024 1

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.

bjdmeest avatar bjdmeest commented on September 27, 2024 1

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.

chrdebru avatar chrdebru commented on September 27, 2024

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.

chrdebru avatar chrdebru commented on September 27, 2024

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.

bjdmeest avatar bjdmeest commented on September 27, 2024

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.

pmaria avatar pmaria commented on September 27, 2024

@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.

@bjdmeest

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.

@chrdebru

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.

chrdebru avatar chrdebru commented on September 27, 2024

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.

DylanVanAssche avatar DylanVanAssche commented on September 27, 2024

There's an agreement, note is in the spec, closing.

from rml-core.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.