Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dependency between input and output type #16

Open
VladimirAlexiev opened this issue Dec 22, 2023 · 0 comments
Open

dependency between input and output type #16

VladimirAlexiev opened this issue Dec 22, 2023 · 0 comments

Comments

@VladimirAlexiev
Copy link

#15 makes the case for multivalued input and output types. And shows two examples of functions

  • a tentative plusOne(integer or decimal) that returns same type as its input argument
  • GeoSPARQL funcs:buffer (or geof:buffer)
    • its signature in the GeoSPARQL standard is given as
      geof:buffer (geom: ogc:geomLiteral, radius: xsd:double, units: xsd:anyURI): ogc:geomLiteral
    • The first parameter and the output are defined more precisely using FNO like this:
funcs:buffer
    a sd:Function, fno:Function ;
    dcterms:source <http://www.opengis.net/doc/geosparql/1.1> ;
    policy:status status:valid ;
    fno:expects (funcs:buffer_param1 funcs:buffer_param2 funcs:buffer_param3 ) ;
    fno:returns (funcs:buffer_output ) ;
    rdfs:isDefinedBy <http://www.opengis.net/spec/geosparql/1.1/req/geometry-extension/query-functions> ;
    rdfs:seeAlso <http://www.opengis.net/doc/geosparql/1.1> ;
    skos:definition "A query function that returns a buffer around the input geometry."@en ;
    skos:prefLabel "buffer"@en .

funcs:buffer_param1 a fno:Parameter ;
    fno:type geo:wktLiteral, geo:gmlLiteral, geo:geoJSONLiteral, geo:kmlLiteral, geo:dggsLiteral  ;
    fno:required "true"^^xsd:boolean ;
    skos:prefLabel "geom"@en .

funcs:buffer_output a fno:Output ;
    fno:required "true"^^xsd:boolean ;    
    fno:type geo:wktLiteral, geo:gmlLiteral, geo:geoJSONLiteral, geo:kmlLiteral, geo:dggsLiteral .

What's missing is the ability to specify the correspondence.

  • I'm not asking for a fully-fledged functional type system: for now it's enough to say "type is the same as the type of that other param"
  • This is useful for input->output (key input determines output) and input->input (first input determines type of second input; eg for a polymorphic function add(num1,num2))
  • It also seems useful to allow the same for required (if input is missing then output would also be missing)

So the example above can become:

funcs:buffer_output a fno:Output ;
    fno:requiredDependsOn funcs:buffer_param1;
    fno:typeDependsOn funcs:buffer_param1.

(Instead of requiredDependsOn I considered requirednessDependsOn but that name is a bit heavy-handed)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant