mOTTR issueshttps://gitlab.com/ottr/spec/mOTTR/-/issues2023-06-29T09:25:30Zhttps://gitlab.com/ottr/spec/mOTTR/-/issues/51Disallow basic supertypes of complex types2023-06-29T09:25:30ZLeif Harald KarlsenDisallow basic supertypes of complex typesFrom Erik:
Since the type system described in mottr is somewhat unrestricted it allows for basic types (other than Top) as supertypes of both lists and constants. For example something like "TopInteger" as the smallest supertype of both...From Erik:
Since the type system described in mottr is somewhat unrestricted it allows for basic types (other than Top) as supertypes of both lists and constants. For example something like "TopInteger" as the smallest supertype of both Integer and List<TopInteger>. It seems to me that the spec is still well-defined in such cases in the sense that there's no ambiguity, but it doesn't work like one might intend with a type like TopInteger. E.g., I would expect the list (1, 2, 3) as argument for a parameter with type TopInteger to be consistently typed. It's not though, because (1, 2, 3) has type NEList<LUB<Top>> which is not compatible with TopInteger (even with my adjustments to compatibility above). Since the spec is still well-defined nothing strictly needs to be done there, but it should be noted that these types maybe don't work as expected and should possibly be disallowed by specifying that Top is the only basic type that is a supertype of list types.https://gitlab.com/ottr/spec/mOTTR/-/issues/50Missing subtype/compatible for Lists2023-06-29T09:24:19ZLeif Harald KarlsenMissing subtype/compatible for ListsFrom Erik:
I think the definition of subtype is lacking in the spec. The spec says:
"`NonEmptyList<P>` is a subtype of `List<Q>` for all types P and Q where P is a subtype of Q."
But it also needs:
"`List<P>` is a subtype of `List<Q>` a...From Erik:
I think the definition of subtype is lacking in the spec. The spec says:
"`NonEmptyList<P>` is a subtype of `List<Q>` for all types P and Q where P is a subtype of Q."
But it also needs:
"`List<P>` is a subtype of `List<Q>` and `NonEmptyList<P>` is a subtype of `NonEmptyList<Q>` for all types P and Q where P is a subtype of Q."
There's a similar problem with the compatible-relation and lists (and the accept-relation in my definitions). The spec says:
"Compatible is the least relation between types such that
- `P` is compatible with all supertypes of P
- `LUB<P>` is compatible with all subtypes of P"
But this does not cover the case with LUB in List-types, for example NEList<LUB<Top>> is only compatible with List/NEList<Top> by this definition. So I think it also needs:
"and for all types P and Q where P is compatible with Q
- `List<P>` is compatible with `List<Q>`,
- `NonEmptyList<P>` is compatible with `List<Q>`,
- `NonEmptyList<P>` is compatible with `NonEmptyList<Q>`."
However, since compatibility is a relation from argument-types to parameter-types, and all non-empty lists have type `NEList<LUB<Top>>`,
then all that really needs to be added to the current spec is that `NEList<LUB<Top>>` is compatible with `List<P>` and `NEList<P>` for every type P.https://gitlab.com/ottr/spec/mOTTR/-/issues/47Overloaded signatures2022-10-04T08:44:00ZMartin G. SkjævelandOverloaded signaturesCan we support signatures with the same name, but with different parameter lists wrt no of arguments and types. Example:
```
SubClassOf[ottr:IRI ?subclass, ottr:IRI ?superclass] and
SubClassOf[List<ottr:IRI> ?subclass, List<ottr:IRI>...Can we support signatures with the same name, but with different parameter lists wrt no of arguments and types. Example:
```
SubClassOf[ottr:IRI ?subclass, ottr:IRI ?superclass] and
SubClassOf[List<ottr:IRI> ?subclass, List<ottr:IRI> ?superclass]
```
Discussion:
Must be able to determine template based on syntactic form of arguments, which makes this feature less interesting, e.g., cannot distinguish between objectProperties and datatypeProperties.
Need more compelling use cases.https://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/42New types2022-09-27T12:00:01ZMartin G. SkjævelandNew typesNew types \[Do 1, LHK MGS\]
* Non-literal, i.e., IRI + lists (and functions, tuples, …)
* Tuples
* Functions
* New convenient supertypes, e.g,. “Number” from “xpath”; time, dateNew types \[Do 1, LHK MGS\]
* Non-literal, i.e., IRI + lists (and functions, tuples, …)
* Tuples
* Functions
* New convenient supertypes, e.g,. “Number” from “xpath”; time, datehttps://gitlab.com/ottr/spec/mOTTR/-/issues/41OTTR metamodel2022-11-24T13:32:58ZMartin G. SkjævelandOTTR metamodelDescribe the relation between templates, instances, modules, FROG functions, type hierarchies, base template definitions.
Discussion:
Should not be possible to extend FROG’s types or base functions.
Do this task before re-implementing ...Describe the relation between templates, instances, modules, FROG functions, type hierarchies, base template definitions.
Discussion:
Should not be possible to extend FROG’s types or base functions.
Do this task before re-implementing lutra core structures
Think about security, provide hashes for everything. Look to maven infrastructure.Martin G. SkjævelandMartin G. Skjævelandhttps://gitlab.com/ottr/spec/mOTTR/-/issues/39Examples of how typing works2022-09-27T12:01:18ZMartin G. SkjævelandExamples of how typing worksHere is some text that could be integrated in the spec:
> Example: if ?X is an argument to two parameters with the types xsd:int and xsd:string, then ?X is not consistently typed according to (1) and given the regular type hierarchy gi...Here is some text that could be integrated in the spec:
> Example: if ?X is an argument to two parameters with the types xsd:int and xsd:string, then ?X is not consistently typed according to (1) and given the regular type hierarchy given in https://spec.ottr.xyz/rOTTR/0.2/ (this image https://spec.ottr.xyz/rOTTR/0.2/type-hierarchy.png), since there exists no type that is subtype of both xsd:int and xsd:string.
>
> Example: Let X be an IRI, say ex:blue, and let ex:blue be an argument to 3 different parameters with the types rdfs:Resource, ottr:IRI, owl:Class. Then X is consistently typed according to , since owl:Class is a subtype of all these types. Since the type of ex:blue is LUB<ottr:IRI>, then this type is compatible with owl:Class. So the term ex:blue is in this case consistently typed.
>
> Example: Let X be an IRI, ex:yellow, and let it be an argument to parameters with the types owl:Class and owl:ObjectProperty. Then in the type hierarchy there exist no subtype of these two types, so the term is not consistently typed. If one wants to support this case one can use a extended type hierarchy that includes types that are subtypes of legal combinations of OWL punning; this is given in https://spec.ottr.xyz/rOTTR/0.2/#2.3_Pun_types.https://gitlab.com/ottr/spec/mOTTR/-/issues/38Tuples2022-10-04T08:44:00ZLeif Harald KarlsenTuplesIntroduce tuples and tuple-types. A tuple-type is a generic type with one type per element in the tuple (e.g. the tuple `(1, 'peter', 1.5)` might have the type `Tuple<xsd:integer, xsd:string, xsd:decimal>`).
It would then make sense to ...Introduce tuples and tuple-types. A tuple-type is a generic type with one type per element in the tuple (e.g. the tuple `(1, 'peter', 1.5)` might have the type `Tuple<xsd:integer, xsd:string, xsd:decimal>`).
It would then make sense to define a list as a generalized type of tuple which only consists of elements of the same type. E.g. the type `Tuple<xsd:integer, xsd:integer, xsd:integer>` would be a subtype of `NEList<xsd:integer>` (both being a valid type for the term `(1, 2, 3)`). We would thus reuse the list-syntax for tuples.
The introduction of tuples has several benefits:
1. Tuples can be used to describe objects, e.g. information about the name, age and occupation of a person can be gathered into a tuple `('Peter', 32, 'Student')`. We can then naturally form lists of such persons, e.g. `(('Peter', 32, 'Student'), ('Mary', 34, 'Professor'))`. Previously this information would have to be split across several lists.
2. FROG-functions can be defined over single elements that are tuples.
3. We can replace argument lists with tuples, and reduce the number of different constructs.
However, the introduction of tuples may also blur the distinction between statements and values, as a tuple may be viewed as a statement. Therefore, we should have a clear description of how and when tuples should be used.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/35make a note that the diagrams are generated from tables2019-05-06T13:23:27ZMartin G. Skjævelandmake a note that the diagrams are generated from tableshttps://gitlab.com/ottr/spec/mOTTR/-/issues/32Core types2019-05-05T19:37:41ZMartin G. SkjævelandCore typesReduce the number of core types to
- top
- bot
- iri
- literal
- list
- nelist
- lub
other types may be included by the user (and we should provide reasonable defaults).Reduce the number of core types to
- top
- bot
- iri
- literal
- list
- nelist
- lub
other types may be included by the user (and we should provide reasonable defaults).https://gitlab.com/ottr/spec/mOTTR/-/issues/31Support modules2022-09-27T12:36:44ZMartin G. SkjævelandSupport modulesSomething similar to modules in Java 9 -- I think. Something that makes it possible to construct or check that the available template library is complete wrt. the instances at hand.
Also, although this is not actively used yet, the aim ...Something similar to modules in Java 9 -- I think. Something that makes it possible to construct or check that the available template library is complete wrt. the instances at hand.
Also, although this is not actively used yet, the aim is to version templates on module level, not individually.
Need to formally define what a module is, and how the relation to other modules should work.https://gitlab.com/ottr/spec/mOTTR/-/issues/30Add colour to diagrams?2019-03-04T11:47:36ZMartin G. SkjævelandAdd colour to diagrams?Colour diagrams like we do in wOTTR?Colour diagrams like we do in wOTTR?https://gitlab.com/ottr/spec/mOTTR/-/issues/29Placement of list expanders2019-02-25T13:55:47ZLeif Harald KarlsenPlacement of list expandersCurrently in mOTTR, list expanders are placed directly on arguments to instances, and not to the instance itself. However, in both stOTTR and wOTTR we have changed this so that the expander is on the instance, and then the arguments to e...Currently in mOTTR, list expanders are placed directly on arguments to instances, and not to the instance itself. However, in both stOTTR and wOTTR we have changed this so that the expander is on the instance, and then the arguments to expand are marked with a flag. Perhaps we should adopt this for mOTTR as well, as this removes the necessity for stating that an instance cannot have arguments with differing list expanders.
Also, there is currently no restriction (in the definition of a `valid template library/dataset` that only lists can have list expanders. This requirement should also be added.https://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/26Permit multiple bodies for a given template2022-10-04T08:43:59ZDanielPermit multiple bodies for a given templateAllowing for multiple bodies allows the same signature to be expanded in different ways. This allows, e.g., a template to be expanded s.t. it is compatible with DOLCE, BFO, etc. Then during expansion process one can specify which upper o...Allowing for multiple bodies allows the same signature to be expanded in different ways. This allows, e.g., a template to be expanded s.t. it is compatible with DOLCE, BFO, etc. Then during expansion process one can specify which upper ontology to use. Suggestion: this might be possible by having multiple sub-properties of ottr:pattern.
Allows for formalizing which upper ontology is used, i.e., it is explicit in a template if it is BFO compliant. This could allow for checking compliance of an ontology with an upper ontology: e.g., if the BFO flag is provided each instance must have a BFO pattern; if it doesn't raise a warning/error.
---------
Can we support templates with the same signature but with different bodies (or a template with multiple bodies)? Motivation: one template with the same “abstract semantics”, but which may be implemented with different vocabularies/ontologies, e.g., metadata described using (1) RDFS only, or (2) Dublin core.
Tasks:
How to specify the different bodies? Suggest to name bodies with URIs, looking to XSLTs modes.
How does expansion work?
Issues:
Discussion:
Identify and describe use cases. It may be that this is the wrong medicine.
Use case: representing a statement in different vocabularies (ISO 15926/BFO, SKOS/DC)
Use case: representing a statement in different equivalent logical forms (RDF triples vs. OWL axioms)
Use case: translate to different OWL profiles (DL, QL, RL)https://gitlab.com/ottr/spec/mOTTR/-/issues/25Define "Well-founded template"?2023-01-23T15:08:00ZMartin G. SkjævelandDefine "Well-founded template"?Suggestion: "A well-founded template is a template that only depends on base templates and other well-founded templates"Suggestion: "A well-founded template is a template that only depends on base templates and other well-founded templates"Leif Harald KarlsenLeif Harald Karlsenhttps://gitlab.com/ottr/spec/mOTTR/-/issues/23Support a "complete" set of expansion modes2022-10-04T08:43:59ZMartin G. SkjævelandSupport a "complete" set of expansion modesWhy do we only support cross, zipMip and zipMax? Is there a standard list of operations that we can implement to claim completeness?
Possibilities:
- reverse: flip the list
- random: randomise the order and/or the size of the list
...Why do we only support cross, zipMip and zipMax? Is there a standard list of operations that we can implement to claim completeness?
Possibilities:
- reverse: flip the list
- random: randomise the order and/or the size of the list
- zip: requires the lists to be of equal sizehttps://gitlab.com/ottr/spec/mOTTR/-/issues/22Support template argument constraints2022-10-04T08:43:59ZMartin G. SkjævelandSupport template argument constraintsAllow templates to include a constraint in the form of an boolean expression over the input arguments that must be evaluated to true to not raise an error. The expression could contain arithmetic.
The use of the constraints could be to ...Allow templates to include a constraint in the form of an boolean expression over the input arguments that must be evaluated to true to not raise an error. The expression could contain arithmetic.
The use of the constraints could be to QA the input, e.g.,
- setting some natural lower and upper bound of numeric variables
- disallowing non-empty strings
Hmm.. what should the expressivity of the language be?https://gitlab.com/ottr/spec/mOTTR/-/issues/20Support keeping instances in expansion2018-10-23T08:00:54ZMartin G. SkjævelandSupport keeping instances in expansionInstead of replacing instances, we could also just *mark* expanded instances and keep them with (or somewhere else) the expansion. For tracing, for provenance, for querying over instances.Instead of replacing instances, we could also just *mark* expanded instances and keep them with (or somewhere else) the expansion. For tracing, for provenance, for querying over instances.