Constraints

[hvarg]

We are changing the way we represent constraints:
Before a SoftwareConfiguration had hasConstraint to specify a constraint as string.
Now a SoftwareConfiguration uses hasConstraint to link a new resource called "sd:Constraint" <https://w3id.org/okn/o/sd#Constraint>.

This new resource has the following properties:

• rdfs:label: Name of the constraint (string)
• sd:description: Description of the constraint (string)
• sd:hasRule: Store a rule (string)
• sd:hasVariable: Link to a sd:VariablePresentation

My original idea was to let the configurations had as many constraints as necessary but link each one to a specific variable.
As example, in a Constraint with hasRule as follows:

ModelExecution(?ex), 
hasModelInput(?ex, ?i),
hasLabel(?i, "cycles_weather_soil"),
hasDataBinding(?i, ?ds),
hasVariable(?ds, ?v),
hasLabel(?v, "average_wind_speed"),
hasValue(?v, ?val),
greaterThanOrEqual(?val, 20)
-> 
isValid(?ex, true),
hasValidityReason(?ex, "Average Wind Speed is >= 20")

we could infer the variable label using the hasVariable property.

But after some meetings I'm not sure if this is enough to fully support constraints.

I can see that the rules use inputs and variables in the code but I'm not sure if we want to link it to the Constraint object.

What do you think @dgarijo @varunratnakar ?
Should I add/remove some property?

[varunratnakar]

Correct me if I'm wrong, but this is what I understand that you are doing now:

SoftwareConfiguration

• hasConstraint: [Constraint] (more than one constraints allowed)

Constraint

• label: Text
• description: Text
• hasRule : Text
• hasVariable: [VariablePresentation] (more than one variables allowed)

I'm happy with the above approach.

Would you be able to give an example where you think this approach might not be enough, as you point out ?

[dgarijo]

Hello,
@varunratnakar , I understand the same as you do.

One question I have is: is the range of hasRule Text (i.e., the rule itself) or a URL to the text file which contains the rule? That seems to be how it is right now, I don't know if you prefer having the actual text in the model catalog in case you want to change it through the UI.

I am ok with the proposal, @hvarg

Thinking of things that could be needed, maybe the ability to bind to parameters comes to mind. In the case of Topoflow we discussed, time_step is a parameter. Basically, the rule sets a parameter value based on the metadata of the input selected. If the input is GLDAS, then timestep is 10800; if it's GPM, it's 1800. Or rather, the timestep metadata variable has to be the same between input X and the parameter timestep

So maybe having a hasParameter would be needed for this purpose. Thoughts?

Also, in the meeting we discussed "constrained variables", but maybe we don't need to link those.

[hvarg]

@dgarijo hasRule is a string so we are able to retrieve the rules directly from the catalog API.
For the moment I've updated to 1.8 without the hasParameter property.

We can link constraints to variables and link that variable on the affected parameter/inputs (both have the property hasPresentation). O think that's more general and allow us to constraint both, parameters and inputs.

One problem: https://w3id.org/okn/o/sd# still points to https://knowledgecaptureanddiscovery.github.io/SoftwareDescriptionOntology/release/1.8.0/index-en.html
how I can change it to point to https://knowledgecaptureanddiscovery.github.io/SoftwareDescriptionOntology/release/1.9.0/index-en.html ?

[dgarijo]

I can do the change, no prob. If you are curious, you need to change: https://github.com/perma-id/w3id.org/blob/master/okn/o/sd/.htaccess

In the newer version HTML, you forgot to add the description in the 1.9 version, but I can do a quick fix.

Note that there may be parameters that have a constraint but no variable (e.g., timestep in TopoFlow), which would not be covered by the approach above.

[dgarijo]

@hvarg I have redirected to 1.9 (pending approval). Do you want me to also add the redirect to sdm?