Review Comment:
This paper presents RML-star, an extension of RML (RDF Mapping Language) to support the new features introduced by RDF-star in RDF. The paper also presents Morph-KGC^star, an implementation of RML-star, and compares it with other implementation of mapping languages supporting RDF-star.
I am generally satisfied by how the authors took into account my remarks on the previous version of this paper. There is however a few remaining points (which, I admit, I missed in my first review) that I believe need fixing, all concerning Algorithm 1.
1) the first input of the algorithm is a "mapping rule", but the RML-star ontology (described in Figure 1), has no explicit concept of *rules* -- instead, it defines different kinds of *maps*. At first, I thought that the parameter 'm' was a TriplesMap, but that interpretation does not work, because the algorithm assumes that 'm' has exactly one of each: Subject Map, Predicate Map (PM), Object Map (OM). By contrast, a TriplesMap may have multiple PMs and OMs. Also, p.7, the authors mention "the mapping rules *within* a non-asserted triples map" (emphasis is mine), so rules and maps are clearly different things. But again: where are the rules in the ontology?
Reading between the lines, I am guessing that rules are somewhat generated from all the SM-PM-OM combinations inside a given map. But that should be explicit!
2) if I try to apply the algorithm to the running example (Listing 8), to the unique rule within the map #dateTM, I come to the conclusion that
* 'subjects' is populated, line 10 of the algorithm, with the following values:
- << :Angelica :jumps "4.80" >>
- << :Katerina :jumps "4.85" >>
* 'predicates' is populated, line 21 of the algorithm, with the following values:
- :date
* 'objects' is populated, line 19 of the algorithm, with the following values:
- "2022-03-21"
- "2022-03-19"
* these 3 collections (ordered? with repetition?) are passed to the function createTriples, line 27, which combines them into triple.
How it decides which subject to combine with which predicate and which object, is absolutely not clear, and should be made explicit.
3) this becomes trickier if I try to apply the algorithm to the more complex example in Listing 6. In my interpretation:
* 'subjects' is now populated with the following values:
- << :Angelica :jumps "4.80" >>
- << :Katerina :jumps "4.85" >>
- << :Angelica :scores "1211" >>
- << :Katerina :scores "1224" >>
* 'predicates' and 'objects' as above.
(NB: this would be even trickier if the OM was *also* a StarMapping generating multiple triples)
→ It is even less clear now how createTriple decides which subjects goes with which predicate and which objects.
I have a hunch that in that case, you are actually considering that #dateTM contains 2 rules instead of 1, which could be summarized as :
- rule1: << [:{PERSON}] :jumps [MARK] >> :date [DATE]
- rule2: << [:{PERSON}] :score [SCORE] >> :date [DATE]
But that brings us back to question 1): you should explain more explicitly what *rules* are, and how you generate them from the maps.
|
