Operator Sketches #25

AdamSobieski · 2022-12-06T00:04:08Z

AdamSobieski
Dec 6, 2022
Collaborator

Transitioning from markup-language-based sketches (see: #21, #22) to ontology-based sketches, here is a Turtle/TriG sketch of a definition of an operator, operator123, with two generic template parameters, T1 and T2 and two parameters, p1 and p2:

@prefix aps: <http://www.w3.org/community/planning/> .
@prefix dc:  <http://purl.org/dc/elements/1.1/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

<http://example.org/#template123>
        rdf:type                aps:OperatorTemplate ;
        dc:description          [ rdf:type  rdf:Alt ;
                                  rdf:_1    [ rdf:type     aps:Data ;
                                              rdf:value    "this is an example operator" ;
                                              dc:format    "text/plain" ;
                                              dc:language  "en"
                                            ] ;
                                  rdf:_2    [ rdf:type     aps:Data ;
                                              rdf:value    "ceci est un exemple d'opérateur" ;
                                              dc:format    "text/plain" ;
                                              dc:language  "fr"
                                            ]
                                ] ;
        aps:effects             [ rdf:type   aps:Data ;
                                  dc:format  "text/..." ;
                                  dc:source  [ rdf:type   aps:Data ;
                                               rdf:value  "... php ..." ;
                                               dc:format  "text/php"
                                             ]
                                ] ;
        aps:name                "operator123" ;
        aps:parameters          [ rdf:type      aps:ParameterList ;
                                  rdf:value     ( [ rdf:type  aps:Parameter ;
                                                    aps:name  "p1"
                                                  ]
                                                  [ rdf:type  aps:Parameter ;
                                                    aps:name  "p2"
                                                  ]
                                                ) ;
                                  aps:requires  [ rdf:type   aps:Data ;
                                                  rdf:value  "function guard(world, p1, p2) { ... javascript ... }" ;
                                                  dc:format  "text/javascript"
                                                ]
                                ] ;
        aps:preconditions       [ rdf:type   aps:Data ;
                                  dc:format  "text/..." ;
                                  dc:source  [ rdf:type   aps:Data ;
                                               rdf:value  "... php ..." ;
                                               dc:format  "text/php"
                                             ]
                                ] ;
        aps:script              [ rdf:type   aps:Data ;
                                  dc:format  "text/javascript" ;
                                  dc:source  [ rdf:type   aps:Data ;
                                               rdf:value  "... php ..." ;
                                               dc:format  "text/php"
                                             ]
                                ] ;
        aps:templateParameters  [ rdf:type      aps:ParameterList ;
                                  rdf:value     ( [ rdf:type  aps:Parameter ;
                                                    aps:name  "T1"
                                                  ]
                                                  [ rdf:type  aps:Parameter ;
                                                    aps:name  "T2"
                                                  ]
                                                ) ;
                                  aps:requires  [ rdf:type   aps:Data ;
                                                  rdf:value  "function guard(world, t1, t2) { ... javascript ... }" ;
                                                  dc:format  "text/javascript"
                                                ]
                                ] .

For clarity, a related JavaScript example might resemble:

var template = domain.get('http://example.org/#template123');
var operator = template.createOperator(world, t1, t2);
var action = operator.createAction(world, a1, a2);

The above Turtle/TriG sketch intends to show:

The generic template's parameters, T1 and T2, have a guard in the form of a JavaScript function, guard.
The operator's parameters, p1 and p2, have a guard in the form of a JavaScript function, guard.
Support for multiple formats (see: Support for Multiple Formats #22) via aps:Data resources and rdf:Alt. Throughout this sketch, extensible aps:Data resources are utilized, even where RDF literals could be used instead, even when the format is text/plain. In this way, algorithms for selecting, preprocessing, and loading content from aps:Data resource alternatives could be consistently reused during deserialization.
A preliminary and simple method, using dc:source, to nest aps:Data resources when data is to be preprocessed from other described data (see: Client-side Preprocessing #21). In these regards, it could be that the provenance ontology (PROV-O) could additionally, or instead, be of use.

The above Turtle/TriG sketch doesn't yet include:

Support for multiple knowledgebases (see: Planning with Multiple Knowledgebases #24). With this capability, the example JavaScript function, guard, might have multiple knowledgebase parameters, parameters in addition to world, or arguments for that first parameter could be or hold an array of, a map of, or an object-based map of knowledgebases.
Binding to or selecting specific scripting functions, e.g., indicating through semantics that the function guard is the one to use from its aps:Data resource.
Defining events, e.g., onload or oninterrupt, which would reference functions in the aps:script aps:Data resource.
Defining property accessors, e.g., duration, which would reference functions in the aps:script aps:Data resource.
A mechanism for aps:Data resources, either in or preprocessed into a Semantic Web format, to be referenceable as named graphs from other aps:Data resources, either in or preprocessed into a Semantic Web format. Note: TriG (application/trig) can express content in named graphs. A matter would then be cross-referencing named graphs across aps:Data resources. If templated semantic contents are to be put into datasets together, then the URI’s for named graphs should somehow contain the template arguments (URL-encoded query string parameters and arguments?) so that Widget<t1> and Widget<t2> could both be in a dataset.

Any thoughts on these initial sketches? Is Turtle/TriG good to use for examples and sketches?

AdamSobieski · 2022-12-06T08:23:03Z

AdamSobieski
Dec 6, 2022
Collaborator Author

Also, could templates, additionally, be expressed as text/php aps:Data resources which are preprocessed into application/trig content?

@prefix aps: <http://www.w3.org/community/planning/> .
@prefix dc:  <http://purl.org/dc/elements/1.1/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

<http://example.org/#template123>
        rdf:type                aps:OperatorTemplate ;
        rdf:value               [ rdf:type   aps:Data ;
                                  dc:format  "application/trig" ;
                                  dc:source  [ rdf:type   aps:Data ;
                                               rdf:value  "... php ..." ;
                                               dc:format  "text/php"
                                             ]
                                ] ;
        aps:templateParameters  [ rdf:type      aps:ParameterList ;
                                  rdf:value     ( [ rdf:type  aps:Parameter ;
                                                    aps:name  "T1"
                                                  ]
                                                  [ rdf:type  aps:Parameter ;
                                                    aps:name  "T2"
                                                  ]
                                                ) ;
                                  aps:requires  [ rdf:type   aps:Data ;
                                                  rdf:value  "function guard(world, t1, t2) { ... javascript ... }" ;
                                                  dc:format  "text/javascript"
                                                ]
                                ] .

Such templates could also provide additional JavaScript:

@prefix aps: <http://www.w3.org/community/planning/> .
@prefix dc:  <http://purl.org/dc/elements/1.1/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

<http://example.org/#template123>
        rdf:type                aps:OperatorTemplate ;
        rdf:value               [ rdf:type   aps:Data ;
                                  dc:format  "application/trig" ;
                                  dc:source  [ rdf:type   aps:Data ;
                                               rdf:value  "... php ..." ;
                                               dc:format  "text/php"
                                             ]
                                ] ;
        aps:script              [ rdf:type   aps:Data ;
                                  dc:format  "text/javascript" ;
                                  dc:source  [ rdf:type   aps:Data ;
                                               rdf:value  "... php ..." ;
                                               dc:format  "text/php"
                                             ]
                                ] ;
        aps:templateParameters  [ rdf:type      aps:ParameterList ;
                                  rdf:value     ( [ rdf:type  aps:Parameter ;
                                                    aps:name  "T1"
                                                  ]
                                                  [ rdf:type  aps:Parameter ;
                                                    aps:name  "T2"
                                                  ]
                                                ) ;
                                  aps:requires  [ rdf:type   aps:Data ;
                                                  rdf:value  "function guard(world, t1, t2) { ... javascript ... }" ;
                                                  dc:format  "text/javascript"
                                                ]
                                ] .

0 replies

william-vw · 2022-12-06T13:13:26Z

william-vw
Dec 6, 2022

@AdamSobieski have you looked into using The Function Ontology to describe these operators? I don't think it would cover all your requirements (such as pre-conditions) but much of it seems covered.

0 replies

AdamSobieski · 2022-12-06T17:36:42Z

AdamSobieski
Dec 6, 2022
Collaborator Author

@william-vw, thank you. I’m presently looking at the Function Ontology. I agree that it could be useful for these purposes; in particular, if we extend it. One conceptual matter involves guards on input parameters or design by contract expressiveness pertaining to both input and output parameters.

The Function Ontology appears to resemble modern programming languages in that it allows type information on parameters and other per-parameter annotations. Beyond per-parameter information and annotations (e.g., those pertaining to optionality/requiredness or those pertaining to nullability), I’m thinking about guard logic where multiple parameters can be used simultaneously in expressions. I'm also thinking about implicit (e.g., global) or explicit first parameters for knowledgebases with which to explore other parameters. For example:

function(kb, p1, p2)
{
  if(kb.isa(p1, 'http://example.org/#type1') && kb.isa(p2, 'http://example.org/#type1') && kb.neq(p1, p2))
  {
    /* ... */
  }
}

Looking at Example 8 from the Function Ontology:

ex:sumFunction
    a                   fno:Function ;
    fno:name            "The sum function"^^xsd:string ;
    dcterms:description "This function can do the sum of two integers."^^xsd:string ;
    fno:solves          ex:sumProblem ;
    fno:implements      ex:sumAlgorithm ;
    fno:expects         ( ex: intParameterA ex:intParameterB ) ;
    fno:returns         ( ex:sumOutput ) .

ex:intParameterA
    a             fno:Parameter ;
    fno:predicate ex:startValue ;
    fno:type      xsd:integer ;
    fno:required  "true"^^xsd:boolean .

ex:intParameterB
    a             fno:Parameter ;
    fno:predicate ex:sumValue ;
    fno:type      xsd:integer ;
    fno:required  "true"^^xsd:boolean .

ex:sumOutput
    a             fno:Output ;
    fno:predicate ex:sumResult ;
    fno:type      xsd:integer ;
    fno:required  "true"^^xsd:boolean .

ex:sumProblem
    a                   fno:Problem ;
    fno:name            "The sum problem"^^xsd:string ;
    dcterms:description "This handles the problem of adding two integers to each other."^^xsd:string ;
    skos:broader        ex:mathProblem .

ex:sumAlgorithm
    a                   fno:Algorithm ;
    fno:name            "The sum algorithm"^^xsd:string ;
    dcterms:description "About how to add two integers to each other."^^xsd:string .

ex:sumExecution
    a             fno:Execution ;
    fno:executes  ex:sumFunction ;
    ex:startValue "2"^^xsd:integer ;
    ex:sumValue   "4"^^xsd:integer .

Resembling design by contract, we could extend the Function Ontology to be able to attach simple functions with provided, inspectable implementations to functions. This might resemble adding ext:guard:

ex:sumFunction
    a                   fno:Function ;
    fno:name            "The sum function"^^xsd:string ;
    dcterms:description "This function can do the sum of two integers."^^xsd:string ;
    fno:solves          ex:sumProblem ;
    fno:implements      ex:sumAlgorithm ;
    fno:expects         ( ex: intParameterA ex:intParameterB ) ;
    ext:guard           ex:sumFunctionGuard ;
    fno:returns         ( ex:sumOutput ) .

Or, it could be the case, from design by contract, that the matter is one of requirements on the input parameters, adding ext:requires:

ex:sumFunction
    a                   fno:Function ;
    fno:name            "The sum function"^^xsd:string ;
    dcterms:description "This function can do the sum of two integers."^^xsd:string ;
    fno:solves          ex:sumProblem ;
    fno:implements      ex:sumAlgorithm ;
    fno:expects         ( ex: intParameterA ex:intParameterB ) ;
    ext:requires        ex:sumFunctionRequires ;
    fno:returns         ( ex:sumOutput ) .

and we could, then, also add ext:ensures for the output parameters:

ex:sumFunction
    a                   fno:Function ;
    fno:name            "The sum function"^^xsd:string ;
    dcterms:description "This function can do the sum of two integers."^^xsd:string ;
    fno:solves          ex:sumProblem ;
    fno:implements      ex:sumAlgorithm ;
    fno:expects         ( ex: intParameterA ex:intParameterB ) ;
    ext:requires        ex:sumFunctionRequires ;
    ext:ensures         ex:sumFunctionEnsures ;
    fno:returns         ( ex:sumOutput ) .

I agree that the Function Ontology could be useful, in particular if extended, e.g., to include guards and/or design by contract requires and ensures for input and output parameters respectively.

What do you think about attaching to function definitions other, simple functions with inspectable implementations, the implementations of which describe input or output parameters beyond per-parameter information and annotations?

3 replies

william-vw Dec 6, 2022

@AdamSobieski I think that's a good idea, but the creators of FNO would be best equipped to answer that question (@bjdmeest)

bjdmeest Dec 7, 2022

Oh, interesting! I'm not sure I'm completely following, but my understanding is that you want to specify a guard on a combination of parameters or outputs as a 'wrapping' function, so that you can specify and execute the guard function separate from the actual function. The distinction between guard functions and actual functions allows to implement and validate design by contract (i.e., only generate the pipeline g(f(a)) if the output of f(a) passes the guard function of g)

Sidenote: you could specify a guard function on individual parameters or outputs, but that doesn't cover the use case of a guard function that relies on correct combinations of, e.g. parameters (see #25 (comment) first code example)

You could probably implement this as an FnO composition: guardedFunction(a, b, c): d is actually the same as normalFunction(guard(a,b,c):a, guard(a,b,c):b, guard(a,b,c):c): d.

Composition is a bit more flexible than specifying ext:requires and ext:ensures as you can combine multiple guard functions (guard1(a,b) combined with guard2(c)), there's a homogeneous processing between normal functions and guard functions, and you can similarly specify data cleansing functions (e.g., this function expects any number larger than 0, or uses 0 otherwise). The downside seems to be the increased verbosity of specifying a composition, and the fact that you'll still need some metadata added to the guard functions to specify them as such.

Good thing is that you could easily use the suggestion you have (ext:requires and ext:ensures) and automatically generate the composition out of it, which might be the best of both worlds.

Also tagging @gertjandemulder since he's actively working on FnO composition :).

AdamSobieski Dec 8, 2022
Collaborator Author

For discussion purposes, we could refer to certain functions (e.g., those referred to via ext:requires, ext:ensures, aps:preconditions, and aps:effects) as being auxiliary to other primary functions.

Interestingly, the implementations of these kinds of auxiliary functions can be considered as parts of the metadata of the primary functions. Inspecting and analyzing the implementations of auxiliary functions like those referred to via ext:requires and ext:ensures can be useful for providing a variety of development-time, compile-time, and runtime features. Inspecting and analyzing implementations of auxiliary functions like those referred to via aps:preconditions and aps:effects (if they are to be modeled as functions) can be utilized in automated planning and scheduling.

Sidenote: you could specify a guard function on individual parameters or outputs, but that doesn't cover the use case of a guard function that relies on correct combinations of, e.g. parameters (see #25 (comment) first code example)

That was my thinking as well, that auxiliary guard functions could, beyond describing individual parameters, usefully describe constraints and conditions that are expected to hold upon combinations of input parameters.

Thank you, I will take a closer look at FnO composition!

AdamSobieski · 2022-12-07T03:27:08Z

AdamSobieski
Dec 7, 2022
Collaborator Author

In addition to the applicability of FnO, some other topics for consideration include:

Comparing and contrasting semantic template processing and function invocation.
- As templates can have parameters, and as template arguments are provided to preprocessing environments, processing templates can resemble function invocation.
Semantic templates can be processed into:
- planning domains and items of planning domains.
- other semantic templates.
- functions perhaps described using FnO.
- scripting content, e.g., text/javascript content.
- first-class semantic graphs or datasets, e.g., application/trig content.
- other scenarios to be considered.
The semantic modeling of functions which return first-class functions, first-class types/classes, first-class semantic graphs, and other interesting cases and scenarios.
Mapping semantically-described functions' implementations to scripting functions in inline script content, e.g., functions in text/javascript content islands contained in semantic graphs or datasets.
Defining events for use with semantic objects such that event handlers can be scripting functions in inline script content, e.g., functions in text/javascript content islands contained in semantic graphs or datasets.

Here is a rough-draft sketch which explores FnO for a case where an abstract function, example:foo, is mapped to an implementation, example:foo_implementation, which has inline JavaScript content:

@prefix dc:      <http://purl.org/dc/elements/1.1/> .
@prefix example: <http://example.org/#> .
@prefix fno:     <http://w3id.org/function/ontology#> .
@prefix fnoc:    <http://w3id.org/function/vocabulary/composition#> .
@prefix fnoi:    <http://w3id.org/function/vocabulary/implementation#> .
@prefix fnom:    <http://w3id.org/function/vocabulary/mapping#> .
@prefix plan:    <http://www.w3.org/community/planning/> .
@prefix rdf:     <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xsd:     <http://www.w3.org/2001/XMLSchema#> .

example:foo  rdf:type  fno:Function ;
        fno:expects  ( example:foo_p1 example:foo_p2 ) ;
        fno:returns  ( example:foo_return ) .

example:foo_implementation
        rdf:type   fnoi:JavaScriptFunction , plan:Data ;
        rdf:value  "function foo(p1, p2) { ... javascript ... }" ;
        dc:format  "text/javascript" .

example:foo_mapping  rdf:type  fno:Mapping ;
        fno:function          example:foo ;
        fno:implementation    example:foo_implementation ;
        fno:methodMapping     [ rdf:type          fnom:StringMethodMapping ;
                                fnom:method-name  "foo"
                              ] ;
        fno:parameterMapping  [ rdf:type                fnom:PositionParameterMapping ;
                                fnom:functionParameter  example:foo_p1 ;
                                fnom:implementationParameterPosition
                                        "1"^^xsd:int
                              ] ;
        fno:parameterMapping  [ rdf:type                fnom:PositionParameterMapping ;
                                fnom:functionParameter  example:foo_p2 ;
                                fnom:implementationParameterPosition
                                        "2"^^xsd:int
                              ] ;
        fno:returnMapping     [ rdf:type             fnom:DefaultReturnMapping ;
                                fnom:functionOutput  example:foo_return
                              ] .

example:foo_p1  rdf:type  fno:Parameter ;
        fno:predicate  example:foo_p1_predicate ;
        fno:required   true .

example:foo_p2  rdf:type  fno:Parameter ;
        fno:predicate  example:foo_p2_predicate ;
        fno:required   true .

example:foo_return  rdf:type  fno:Output ;
        fno:required  true ;
        fno:type      xsd:boolean .

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Operator Sketches #25

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 4 comments 3 replies

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Select a reply

Operator Sketches #25

AdamSobieski Dec 6, 2022 Collaborator

Replies: 4 comments · 3 replies

AdamSobieski Dec 6, 2022 Collaborator Author

william-vw Dec 6, 2022

AdamSobieski Dec 6, 2022 Collaborator Author

william-vw Dec 6, 2022

bjdmeest Dec 7, 2022

AdamSobieski Dec 8, 2022 Collaborator Author

AdamSobieski Dec 7, 2022 Collaborator Author

AdamSobieski
Dec 6, 2022
Collaborator

Replies: 4 comments 3 replies

AdamSobieski
Dec 6, 2022
Collaborator Author

william-vw
Dec 6, 2022

AdamSobieski
Dec 6, 2022
Collaborator Author

AdamSobieski Dec 8, 2022
Collaborator Author

AdamSobieski
Dec 7, 2022
Collaborator Author