DylanVanAssche
commented
6 months ago There is an inconsistency between Figure 2 and Table in Section 4.2 (e.g., the domain of rml:compression is rml:Target, whereas in the table it is rml:LogicalTarget.
rml:compression and rml:encoding should be part of rml:Target which can be an object with rml:target predicate.
Other vocabularies can be used an object there as well to allow the 'access' to the Target. Compression and encoding are considered 2 things that enable access to the target. The serialization on which the quads are serialized and put inside the target are not considered access.
The table is wrong here it seems. The domain was changed a few times, probably forgot to fix it there.
Furthermore, should not we not specify rml:serialization in logical sources as well? For instance, if I am reading a binary JSON file (BSON), then rml:serialization could be used to denote this fact which is not currently captured by rml:referenceFormulation rml:JSONPath.
Serialization is the format for serializing quads. JSONPath is the reference formulation and this can be used for BSON, same for JSONL. In https://github.com/kg-construct/rml-core/issues/113 we are discussing how we should better document the reference formulations and other things regarding implementation, this issue feels related to this.
There is an inconsistency between Figure 2 and Table in Section 4.2 (e.g., the domain of
rml:compressionisrml:Target, whereas in the table it isrml:LogicalTarget.For consistency with logical sources, maybe the figure is "correct", however I wonder why
rml:serializationhas been put as a property ofrml:LogicalTarget. Would it not make it more sense to put it together with compression and encoding details?Furthermore, should not we not specify
rml:serializationin logical sources as well? For instance, if I am reading a binary JSON file (BSON), thenrml:serializationcould be used to denote this fact which is not currently captured byrml:referenceFormulation rml:JSONPath.