kg-construct / rml-fnml Goto Github PK

There is a mismatch between the naming of fnml:outputMap which points to a fnml:ReturnMap. In other parts of the language we use the same terminology for the property and object, e.g, subjectMap - SubjectMap, objectMap - ObjectMap etc. Why not keep the same regimen here? I propose we rename fnml:outputMap to fnml:returnMap, and have fnml:return as shorthand value.

So you'd get:

<>
    fnml:execution <#Execution> ; # Link to an FNML Execution
    fnml:returnMap [
        a fnml:ReturnMap ;
        rr:constant grel:stringOut # Specify which return of the referenced function to use
    ] .

or with the shorthand

<>
    fnml:execution <#Execution> ; # Link to an FNML Execution
    fnml:return grel:stringOut ;

Hi there,

In the RML+FnO spec, subject, predicate, parameter, [...] maps have an associated subclass of the termMap class.

I wonder what is the rationale behind not having a specific (termMap) subclass for value maps.

Came from kg-construct/rml-core#1, depends on how we handle kg-construct/mapping-challenges#29 , and is related to #3

Suggestion: the ability to describe a join condition that does not return the subject of a triples map, but something else, maybe it returns the iteration from a different logical source that matches the condition, so that we could use a reference formulation to take any data field from that iteration (in RML)

• #16
• #17

introduced changes to the ontology, please update the test-cases to match

Recommended by @pchampin: https://inria.hal.science/hal-01402901v1/file/RR-8982.pdf

In light of the choice for a single rml namespace, names like rml:execution may not be descriptive enough anymore. I think we should consider to rename some of them.

For example in the case of rml:execution, rml:functionExecution is clearer.

With the introduction of rml:ExpressionMap, the domain of rml:execution , rml:return, and rml:returnMap, should now be changed to rml:ExpressionMap.
This makes functions applicable on anything that is an rml:ExpressionMap , like rml:DatatypeMap, rml:LanguageMap etc.

I noticed that in defining the fnml:ReturnMap and fnml:Input we're following a double standard. We're defining the fnml:Input based on both abstract definition in FnO (i.e., parameter) and the practical level (i.e., the reference to the value in the real data source), while, in the case of fnml:ReturnMap we only define based on the abstract level (i.e., we're not allowing the definition of the return value in the real data source). Maybe I'm missing something, otherwise, I think we need to modify the definition of fnml:ReturnMap. Lert me know if you want me to pull request with the modification :)

• Triples Map, Expression Map, etc. still points to rml.io in the spec. This should be the W3ID URL.
• triples map, expression map, etc. are written without capitals while they are classes.

Can these be adjusted?

e.g. what if a function returns an RDF literal with language tag?

New structure:

• folder spec with all the resources for the specification (the current content of the repo)
• folder ontology, which I think is coming from #15
• folder shapes, coming from #18
• folder test-cases, for #19

Other changes:

• The new name of the repo should be: rml-fnml

Hi,

I have gone through the spec, it is quite clear, nice work :)

I think I found a typo, or maybe I misunderstood, in Example 6: use nested function, the current mapping for <#Execution2> is:

<#Execution2> a fnml:Execution ;               # First, replace spaces with dashes from the `name` reference
    fnml:function grel:string_replace ;
    fnml:input
        [
            a fnml:Input ;
            fnml:parameter grel:valueParam ;
            fnml:valueMap [
                rml:reference "name"
            ]
        ] ,
        [
            a fnml:Input ;
            fnml:input grel:param_find ;
            fnml:value " "
        ] ,
        [
            a fnml:Input ;
            fnml:input grel:param_replace  ;
            fnml:value "-"
        ] .

However, I was expecting:

<#Execution2> a fnml:Execution ;               # First, replace spaces with dashes from the `name` reference
    fnml:function grel:string_replace ;
    fnml:input
        [
            a fnml:Input ;
            fnml:parameter grel:valueParam ;
            fnml:valueMap [
                rml:reference "name"
            ]
        ] ,
        [
            a fnml:Input ;
            fnml:parameter grel:param_find ;
            fnml:value " "
        ] ,
        [
            a fnml:Input ;
            fnml:parameter grel:param_replace  ;
            fnml:value "-"
        ] .

That is, replacing the fnml:input with fnmlparameter.

Test-cases should use a single prefix rml: <http://w3id.org/rml/>, please drop all the rest from r2rml, semweb IRIs, ql, etc.

Given that the FNO definitions are necessary to know what a function like grel:toUpperCase means and how it is mapped to a concrete function implementation. Should these descriptions not be part of the test cases?

The spec says that

the default term type depends on whether the term map is an object map or not.

which points to the R2RML spec which says

If the term map does not have a rr:termType property, then its term type is:

• rr:Literal, if it is an object map and at least one of the following conditions is true:
  • It is a column-based term map.
  • It has a rr:language property (and thus a specified language tag).
  • It has a rr:datatype property (and thus a specified datatype).
• rr:IRI, otherwise.

Reading this I would say an rr:ObjectMap that is also a fnml:FunctionMap with no rr:termType, rr:language or rr:datatype specified should by default return an rr:IRI. (Note: this is how it is implemented in CARML currently)

In FnO test case RMLFNOTC0000-CSV however, the expected term type in such a case is rr:Literal. We need to clarify this.

Would be nice to have test cases covering the complete specification:

• Validating SHACL shapes from #18
• Implementations validating their code
• ...

• 0000 relies on a UUID function, but that always yields a different result
• Tests still rely on old representations of sources
• should the rml:constant "name" ; in 0002 not be changed to rml:reference "name" ; The test description states that it tests whether the "false reference" is caught, but the test uses a constant and I do not see what is wrong with this mapping. The spec does not specify that constant expression maps are not allowed for input value maps.
• Is id-lab:toUpperCaseURL a good function for test case 0004? It is underspecified and it does not play nicely with the usual behavior of trying to generate an absolute IRI. I would have understood it the test data contained a IRI, but the test case now assumes that the values is put next to http://
• http://VENUS is not a valid absolute IRI
• Ibid for 0005
• 0006 -> the function adds http:\\ (lower case) when it is missing, but transforms http:// into HTTP:// when it is provided.
• We should have a variant with rml:return other than the nested function call. Maybe 0001?

A fnml:FunctionMap always returns an RDF term [[rdf-concepts]] or list thereof,
thus already has things such as termtype, datatype, etc. defined.
We probably want to allow to override these datatypes within an RML mapping.
If so, do we need to specify how to override these datatypes?
Are there standardized RDF coercion rules?
Is this related to https://www.w3.org/TR/r2rml/#natural-mapping?

Came from kg-construct/rml-core#1

it is possible to nest functions (see eg https://github.com/RMLio/rml-fno-test-cases/blob/master/RMLFNOTC0018-CSV/mapping.ttl), so functions on top of functions, but not functions on top of joins.

• No cardinality constraints for return maps
• Spec refers to property rml:InputValueMap [ ... ], but it should be rml:inputValueMap [ ... ]
• What happens with multi-valued expression maps used in parameter, return, function, and inputvalue maps?
• Default term type for input value maps is not specified. It is a subclass of Term maps with only special conditions for object maps. Is the default term type for an input value map rml:Literal?

fnml:OutputTermMap is now introduced as a type of term map. However, I don't think we should introduce it as such.
I think we should introduce it as being an aspect of a term map. Just as other expressions can be aspects - rr:constant or rr:template etc. In R2RML they talk about constant-valued term map, and template-valued term map, etc. So here, we could just talk about function-valued term maps.

Of course we could create specific classes for all possible term map and expression combinations, so you could get a FunctionValuedGraphMap for example, but that might not be necessary.

If we do wish to introduce these specific classes I would create class intersections between specific term maps and specific expression maps (expression map is proposed in kg-construct/rml-core#46), but I think we would need to have a good use case for this.

Another reason not to position it as a term map is to be able to use functions in non-term map constructs, e.g. languageMaps or joins as proposed in kg-construct/rml-core#53

As we agreed, all spec diagrams should look similar. Now a diagram is provided but it's not similar to the rest.
I think the best way to do it is that @anaigmo will provide the figure and then @bjdmeest can add it to the spec

I think we need to generalize the Figure 1 Visual overview of connections FNML to also cover the reference to functions as subject and probably predicate, right?