Specify rr:parent as a shortcut reference property of rr:parentMap (and similar for rr:child as shortcut reference property for rr:childMap)

[bjdmeest]

The RMLMapper supports rml:parentTermMap: https://github.com/RMLio/rmlmapper-java/search?q=parentTermMap

:om_5 a rr:ObjectMap;
    rr:parent "friendID".

EQUALS

:om_5 a rr:ObjectMap;
    rml:parentTermMap :ptm_0.
:ptm_0 rml:reference "friendID".

This allows us to support joining on, e.g. constants (which is interesting when you want to join on IDs AND, e.g. filter on constant values in the join condition) or templates or function values.
It's a subtle extension, but greatly increases the complexity of the join operator.
Even if joining in RML gets a revamp, this is mostly a suggestion to allow for term maps instead of only references.

[pmaria]

+1

Although I suggest calling it parentMap, since these aren't Term Maps in that they do not generate RDF Terms.
I would then also propose to introduce a childMap wrt rr:child.

[bjdmeest]

+1

Although I suggest calling it parentMap, since these aren't Term Maps in that they do not generate RDF Terms. I would then also propose to introduce a childMap wrt rr:child.

Ah yes, +1 on both, I updated the title

[andimou]

Regarding the shortcut:

rr:subject, rr:predicate and rr:object act as shortcuts of rr:subjectMap, rr:predicateMap and rr:objectObjectMap respectively when these are combined with rr:constant.

However, if we keep rml:child and rml:parent as shortcuts as we see them in R2RML spec, then these are the combination of rml:childMap and rml:parentMap respectively with rml:reference.

Do you think that these could be confusing as the shortuct comes for a different expression map?

[bjdmeest]

I personally don't see an issue with that, but we could also do the same as we do in YARRRML: use template as shortcut property, that has ambiguity with the URI encoding (which we solved in YARRRML by translating such a shortcut containing only a template and nothing else as a reference, but that's borderline hacking :) )

[andimou]

I think that this doesn't solve the problem and it's not exactly the same as with YARRRML.

In YARRRML we intentionally simplified certain things with respect to the references but in the case of RML we are more explicit, ie the template generates an IRI, unless specified differently, the reference generates a literal, unless specified differently and the constant generates an IRI unless specified differently. In YARRRML the template is hacked to simplify things for the users but I think that we don't want this oversimplification for RML.

The question here is a bit different, do we agree that in the case of term map, the shortcut comes with the constant-valued expression map, whereas in the case of joins the parent/child map coes with the reference-valued expression map?

[bjdmeest]

The question here is a bit different, do we agree that in the case of term map, the shortcut comes with the constant-valued expression map, whereas in the case of joins the parent/child map coes with the reference-valued expression map?

Yes.

Second to that, what I meant to say was that I proposed another way to solve the issue: drop "constant-valued" AND "reference-valued" shortcuts and replace them all with a "template-valued" shortcut, which means the same processing rule holds for rr:subject, rr:predicate and rr:object and rml:child and rml:parent (and be backwards compatible with the original [R2]RML)

[pmaria]

I agree that defining a new type of shortuct property shouldn't be an issue.

[andimou]

drop "constant-valued" AND "reference-valued"

and then make the termtype mandatory? ie what would be the default term type when you generate something from these shortcuts? If template-valued, then it should be an IRI.

[bjdmeest]

what would be the default term type when you generate something from these shortcuts

The default term type would be the same as for the non-shortcut, that behavior wouldn't change, which in this case would indeed be IRI. It was merely a suggestion, I prefer the reference-valued shortcut property

[dachafra]

This was marked in the last agenda as a "join" issue, but I think it is more core than join, or am I wrong?

[andimou]

I think this is already on the spec and it's safe to be closed.