mOTTR issueshttps://gitlab.com/ottr/spec/mOTTR/-/issues2023-04-18T07:45:38Zhttps://gitlab.com/ottr/spec/mOTTR/-/issues/27Two optionals, but we need at least one value2023-04-18T07:45:38ZJohan Wilhelm KlüwerTwo optionals, but we need at least one valueWorking on "number range custom datatypes". I want a template that can take a minimum, a maximum, or both -- but if *both* are missing, then nothing should be returned.
Here is the template:
```
<<template-prefixes>>
@prefix : <http://...Working on "number range custom datatypes". I want a template that can take a minimum, a maximum, or both -- but if *both* are missing, then nothing should be returned.
Here is the template:
```
<<template-prefixes>>
@prefix : <http://norsok.org/templates/RestrictionMinMaxInclusiveExclusive#> .
<http://norsok.org/templates/RestrictionMinMaxInclusiveExclusive> a ottr:Template ;
ottr:hasParameter
[ ottr:index 1; ottr:nonLiteralVariable :restriction ] ,
[ ottr:index 2; ottr:nonLiteralVariable :xsdDatatype ] ,
[ ottr:index 3; ottr:literalVariable "minimum" ; ottr:optional true ] ,
[ ottr:index 4; ottr:literalVariable "maximum" ; ottr:optional true ] .
:restriction rdf:type rdfs:Datatype ; owl:onDatatype :xsdDatatype ;
owl:withRestrictions ( [ xsd:minInclusive "minimum" ] [ xsd:maxExclusive "maximum" ] ) .
```
When both the minimum and maximum are empty, the following anonymous individual is output. Is there a way to avoid it?
```
[] a rdfs:Datatype ;
owl:onDatatype xsd:double ;
owl:withRestrictions
([] []) .
```https://gitlab.com/ottr/spec/mOTTR/-/issues/5Support imports?2022-10-04T08:43:58ZMartin G. SkjævelandSupport imports?Support imports of other (st)OTTR files?
css style: `@import("url here")`Support imports of other (st)OTTR files?
css style: `@import("url here")`https://gitlab.com/ottr/spec/mOTTR/-/issues/37Functional vs. Predicate Templates2022-10-04T08:43:59ZMartin G. SkjævelandFunctional vs. Predicate TemplatesSupport templates that return a value.
Suggestion is to specify a return resource in the template head and replace the resource that represents the template instance (often a blank node: [] ottr:templateRef <someTemplate>) with the retu...Support templates that return a value.
Suggestion is to specify a return resource in the template head and replace the resource that represents the template instance (often a blank node: [] ottr:templateRef <someTemplate>) with the return value.
Should then probably replace ottr:templateRef with two different properties to indicate is the called template is a function or a predicate, also introduce subclass(es) of ottr:Template for the same purpose.
----------
Allow templates to return a value. Why? This allows for an elegant nesting of templates, and avoids also requiring that the return argument must occur as a parameter as it is now. This is especially the case when templates generate a blank node.
Tasks:
How to specify the value to be returned.
Where to return the value, i.e., e.g, correct placement in the resulting RDF graph
Can these templates be “called” without receiving the returned value?https://gitlab.com/ottr/spec/mOTTR/-/issues/8Template-defining template2022-09-27T17:17:50ZMartin G. SkjævelandTemplate-defining templateSince both an (OTTR-RDF) template's definition and expande body is just a set of triples, we can define a template which expansion is a template definition. For instance as:
Define(template, args, ins1, ins1Args, ins2 --o, ins2Args ...Since both an (OTTR-RDF) template's definition and expande body is just a set of triples, we can define a template which expansion is a template definition. For instance as:
Define(template, args, ins1, ins1Args, ins2 --o, ins2Args --o) :: {
template a ottr:Template;
ottr:withVariables args .
[] a ottr:TemplateInstace;
ottr:templateRef ins1;
ottr:withValues ins1Args .
[] a ottr:TemplateInstace;
ottr:templateRef ins2;
ottr:withValues ins2Args .
}
assuming we have a template on the form Triple(s, p, o) :: { s p o . }, to allow for triples in body.
However, in the current OTTR-spec the above definition is not well-defined, as the head of the template is not ambiguous (we have two elements with rdf:type ottr:Template). There are several ways around this problem, e.g. we can use quads/named graphs to explicitly denote the head and body of the template:
:HEAD {
ottr:define a ottr:Template;
ottr:hasParameter [ ottr:index 1; ottr:variable :Template ] ,
[ ottr:index 2; ottr:variable :Args ] ,
[ ottr:index 3; ottr:variable :Ins1 ] ,
[ ottr:index 4; ottr:variable :Ins1Args ] ,
[ ottr:index 5; ottr:variable :Ins2; ottr:optional true ] ,
[ ottr:index 6; ottr:variable :Ins2Args; ottr:optional true ] .
}
:BODY {
:Template a ottr:Template;
ottr:withVariables :Args .
[] a ottr:TemplateInstace;
ottr:templateRef Ins1;
ottr:withValues Ins1Args .
[] a ottr:TemplateInstace;
ottr:templateRef Ins2;
ottr:withValues Ins2Args .
}
We can also introduce a new ottr:TemplateTemplate-class which instances can have ottr:Template-s in body. Or, we could just implement Define explicitly in lurta, without a "normal" definition.
The Define-template above only takes two arguments, and must therefore be nested to allow for more than two instances in a body. An alternate form which removes this restriction, but which needs more complex list-functionality (zip) can be defined (in quasi-DL syntax) as:
Define(name, params, argss, ts) :: { "name(params) :: { zip(ts, argss) } " . }Leif Harald KarlsenLeif Harald Karlsenhttps://gitlab.com/ottr/spec/mOTTR/-/issues/43Support fundamental (and complex) templates like fold internally only?2022-10-04T08:44:00ZMartin G. SkjævelandSupport fundamental (and complex) templates like fold internally only?Support the functionality of fundamental templates only in software, like:
- lambda template
- foldsSupport the functionality of fundamental templates only in software, like:
- lambda template
- foldshttps://gitlab.com/ottr/spec/mOTTR/-/issues/10implement "gate template"2022-10-04T08:43:58ZMartin G. Skjævelandimplement "gate template"implement a type of template as a "switch", that passes arguments on to other templates dependent on the existence of a given set of arguments.
Something like:
My-switch-template(a, b, c) ->
other-template-A(a,b)
other-template-B(a...implement a type of template as a "switch", that passes arguments on to other templates dependent on the existence of a given set of arguments.
Something like:
My-switch-template(a, b, c) ->
other-template-A(a,b)
other-template-B(a,c)
some or all of the the arguments to My-switch-template may be missing.
A gate template can only contain calls to other templates, and not ontology axioms, I think.https://gitlab.com/ottr/spec/mOTTR/-/issues/12template views2022-10-04T08:43:58ZMartin G. Skjævelandtemplate viewsSupport declaration of custom "template instance views". The purpose of such views are to allow "ordinary" RDF to be used as template instances and serve the purpose of, e.g., lifting simple RDF shapes into richer ontology structures. Th...Support declaration of custom "template instance views". The purpose of such views are to allow "ordinary" RDF to be used as template instances and serve the purpose of, e.g., lifting simple RDF shapes into richer ontology structures. The view can be thought of as a query whose results are template instances of a specified template, i.e., similar to m-statements.
Example: The following could be template view:
`?a :point [ :lat ?lat; :long ?long ]`
which could represent the template instance `Point(a, lat, long)`https://gitlab.com/ottr/spec/mOTTR/-/issues/13support template extension2022-10-04T08:43:59ZMartin G. Skjævelandsupport template extensionuseful when use adding just more parameters
or just restricting parameter types.useful when use adding just more parameters
or just restricting parameter types.