Update argument mode for list:in

[eyusupov]

It seems that $s is incorrectly specified as the output-only parameter, while it can be both input and output.

[william-vw]

@eyusupov You can always give a concrete value for an output; in that case, the reasoner will simply check whether the statement is true or not. E.g., using list:length:

(1 2 3) list:length 3

What defines an "input" parameter is that it has to be bound before the statement can be evaluated. E.g., we cannot evaluate the following (if ?x cannot be bound):

?x list:length 3

Since we need to know the list to determine its length. Length cannot be an input here, since we cannot determine a list based on its length; i.e., the information does not "flow" in that direction.

A good example of in/output modes is list:append. Here, either subject list elements, or the object, can be an input parameter: https://editor.notation3.org/s/8n3juXNi https://editor.notation3.org/s/wyFjI7YN

I.e., information can flow from the object to the subject list elements, or vice-versa.

[eyusupov]

@william-vw Thank you for the explanation, but for the list:in the spec gives this example:

{ ?what list:in ( "dog" "penguin" "cat" ) . } => { :result :is ?what . } .

where ?what is $s argument. In that case it is not bound and the information flows from $o there, so what? is the output parameter.

However also it gives this example:

{ "cat" list:in ( "dog" "penguin" "cat" ) . } => { :result :is true . } .

where $s is actually bound and acts as the input parameter, and probably it could be said that the information flows from $s and $o to... the result I guess?

I understand that we can't express the question what lists contain this element with a list:in. However, in the previous case cat does seem to serve like an input parameter.

It is also a bit weird that list:in is the only builtin predicate in the spec with a - mode for subject, which is what initially got me alarmed. What do you think?

[eyusupov]

If I understand correctly, the current specification

$s-[*] list:in $o+

covers this case

{ ?what list:in ( "dog" "penguin" "cat" ) . } => { :result :is ?what . } .

(subject is ouput), but in order to also cover the second case, that is:

{ "cat" list:in ( "dog" "penguin" "cat" ) . } => { :result :is true . } .

the specification has to allow it to also be an input parameter:

$s?[*] list:in $o+

[william-vw]

@eyusupov Note that we borrowed the concept of argument modes from prolog, where they help to explain the intended semantics. They can be quite confusing IMO, due to the reasons you have outlined.

A rule of thumb here is that, if the builtin can work with only the parameter (e.g., subject), then the parameter is an input. list:in cannot work only with the subject (we cannot determine the list based on a single element), so the subject can only be an "output" here. (In some rare cases, a parameter can also be input if it provides additional information to the builtin, such as for collectAllIn.)

Note that, if a value is provided for the output, it simply means that the statement is true if the output equals that value. The value is still not used as input to the builtin. I think that this may be a source of some of the confusion.

For instance, log:uri can work "in both directions":

$s? log:uri $o?

The builtin can work with only the subject (will generate a string), or only the object (will generate a uri). E.g.: https://editor.notation3.org/s/kILB2HZw https://editor.notation3.org/s/uLYPB3Rp

Most math operations can work in both directions (e.g., if the object is given, math:cos will calculate its arccosine, i.e., the inverse of cosine.)

But, to determine whether something is greater than something else (math:greaterThan), both parameters need to be given as input - we cannot determine that given only one parameter.

[eyusupov]

Thank you for the detailed explanation, it's clear now.