T-box strategy for the URI's and their validation

[samwaseda]

In #278, I replaced all the properties by the ones defined in PMDco. However, there is one significant change that has to be addressed for the recipe ontology. In my old implementation, the triples looked like this¹:

flowchart LR
output_state_1 -- rdfs:subClassOf --> uri_1
process_1 -- has_part --> output_state_1 -- has_participant --> some_data_or_thing_2
process_2 -- has_part --> input_state_2 -- has_participant --> some_data_or_thing_2
input_state_2 -- rdfs:subClassOf --> uri_2

Loading

Again: This is T-box, i.e. rdfs:subClassOf is to be replaced by a in the a-box.

But @joergwa stated it has to be like this:

flowchart LR
process_1 -- has_part --> output_state_1 -- has_participant --> some_data_or_thing_2
process_2 -- has_part --> input_state_2 -- has_participant --> some_data_or_thing_2
some_data_or_thing_2 -- rdfs:subClassOf --> uri_1
some_data_or_thing_2 -- rdfs:subClassOf --> uri_2

Loading

Quite obviously uri_1 must be a subclass of uri_2. I have already stated this problem in #278, but so far I haven't found a really convincing solution for the validation method, because pretty obviously from the graph above, you cannot know which of the two URI's was defined for the input and which one for the output (or one was defined in the first place).

In the followup discussion with @joergwa, I was going more towards the direction of validating during the graph construction, but in the end I think I would like to stick to the following two points:

• Validation runs once the recipe ontology is fully constructed
• Nodes should be recoverable from the recipe ontology (not directly related to the problem I'm dealing with here, but creates an important condition)

Based on this, I thought about using owl restriction for this part as well, i.e.

flowchart LR
process_1 -- has_part --> output_state_1 -- has_participant --> some_data_or_thing_2
process_2 -- has_part --> input_state_2 -- has_participant --> some_data_or_thing_2
some_data_or_thing_2 -- rdfs:subClassOf --> uri_1
input_state_2 -- rdfs:subClassOf --> Bnode
Bnode -- rdfs:subClassOf --> restriction[owl:Restriction]
Bnode -- owl:onProperty --> has_participant
Bnode -- owl:someValuesFrom --> uri_2

Loading

I asked ChatGPT whether this makes sense. The answer: No. The reason is pretty simple: input_state_2 - has_participant - uri_2 makes sense only if input_state_2 is an instance. In other words, this triple basically means "there may be an instance of input_state_2 which may have an instance of uri_2 connected via has_participant". I can understand why. After all, the workflow recipe is also a bit like an instantiation itself as well. Anyway, ChatGPT told me that it's not invalid, even if it makes little sense, so I'm gonna stick to this expression, because this (probably) allows me to run validation, and fulfills the two conditions that I stated above.

Footnotes

1. I replaced participates_in by has_participant, because the expression becomes easier for the OWL restriction ↩

[samwaseda]

And I very much mourn your absence @liamhuber 😭

[samwaseda]

At this point @liamhuber would have said "I don't like this idea, because of ABCXYZ (to be replaced by one of Zen of python stuff, potentially not even marginally related but still used as a justification 😎)". Then I would have said, "fine, how about this?" and proposed the following:

flowchart LR
node_A -- bfo:has_part --> node_A.outputs.X -- ro:has_participant --> uri_1
node_A -- iao:is_about --> my_workflow.node_A_0 -- bfo:has_part --> my_workflow.node_A_0.outputs.X -- ro:has_participant --> my_workflow.node_A_0.outputs.X.value -- rdfs:subClassOf --> uri_1
node_B -- iao:is_about --> my_workflow.node_B_0 -- bfo:has_part --> my_workflow.node_B_0.inputs.Y -- ro:has_participant --> my_workflow.node_A_0.outputs.X.value
node_B -- bfo:has_part --> node_B.inputs.Y -- ro:has_participant --> uri_2

Loading

Here, I used the tags that I would also use in the knowledge graph (instead of process_1 etc.). This one is not only cleaner than that restriction idea, but also it will be a lot easier to extract atomic nodes, because you would only need to extract what's written after is_about. It might be somewhat cumbersome to write SPARQL to compare uri_1 and uri_2, because they are not pretty far away from each other, but I'll give it a try.

[niklassiemer]

Is all of this T-Box? or is e.g. my_workflow.node_B_0 now an instance? If have the feeling, that there are two layers involved (which is probably fine :) ) . The is_abouts also go into the wrong direction, don't they?
Oh, I think I just got confused by the node_B, which was named process_2 before - thus I am quite sure you stay on the T-Box layer.

[samwaseda]

Yes, it's T-Box, but I think your confusion is totally valid - in a way, it's some instantiation, especially because I don't think it actually makes sense to talk about validation about true classes.

[samwaseda]

I realized that with the version I posted above, I cannot really know which input/output realizes which input/output in the workflow. So it should look like this:

flowchart LR
node_A -- bfo:has_part --> node_A.outputs.X -- bfo:has_part --> node_A.outputs.X.value -- ro:has_participant --> uri_1
node_A.outputs.X -- iao:is_about --> my_workflow.node_A_0.outputs.X
node_A -- iao:is_about --> my_workflow.node_A_0 -- bfo:has_part --> my_workflow.node_A_0.outputs.X -- ro:has_participant --> my_workflow.node_A_0.outputs.X.value -- rdfs:subClassOf --> uri_1
node_B -- iao:is_about --> my_workflow.node_B_0 -- bfo:has_part --> my_workflow.node_B_0.inputs.Y -- ro:has_participant --> my_workflow.node_A_0.outputs.X.value
node_B.inputs.Y -- iao:is_about --> my_workflow.node_B_0.inputs.Y
node_B -- bfo:has_part --> node_B.inputs.Y -- bfo:has_part --> node_B.inputs.Y.value -- ro:has_participant --> uri_2

Loading