For part of this project that deals with drawing abstractions/multitools from concrete workflows, there are two phases:
First, repository construction; then, workflow abstraction. The second phase is not very complicated, because nothing can be added to the repository: we only check if an abstraction exists with matching tool URI & CCT & CCD, and error out otherwise. The first phase is where the logic needs to be improved.
If everything matches, there's already a abstraction and you don't have to do anything. And sometimes the course of action is straightforward: just make a new abstraction. But there are 4 more cases when it's more complicated:
The CCD type is a sub- or supertype and the URI matches, but the CCT expression doesn't. In this case, we have to make a new abstraction, but should issue a warning, because it's quite likely that the CCT expressions mismatch by mistake.
The URI and CCT expression match, but the CCD type is actually a supertype. We can quietly expand the signature.
The CCT expression matches and the CCD type is a subtype, but the URI doesn't match. We can quietly add the URI to the abstraction.
The CCT expression matches, but the URI doesn't match, while the CCD type is a supertype. This means that we must both expand the CCD type of the abstraction and add an extra tool to it, which is suspicious enough to warrant a warning.
Furthermore, finding the abstraction should be done differently for a workflow than for a concrete tool, because we can work off different assumptions.
For part of this project that deals with drawing abstractions/multitools from concrete workflows, there are two phases:
First, repository construction; then, workflow abstraction. The second phase is not very complicated, because nothing can be added to the repository: we only check if an abstraction exists with matching tool URI & CCT & CCD, and error out otherwise. The first phase is where the logic needs to be improved.
If everything matches, there's already a abstraction and you don't have to do anything. And sometimes the course of action is straightforward: just make a new abstraction. But there are 4 more cases when it's more complicated:
The CCD type is a sub- or supertype and the URI matches, but the CCT expression doesn't. In this case, we have to make a new abstraction, but should issue a warning, because it's quite likely that the CCT expressions mismatch by mistake.
The URI and CCT expression match, but the CCD type is actually a supertype. We can quietly expand the signature.
The CCT expression matches and the CCD type is a subtype, but the URI doesn't match. We can quietly add the URI to the abstraction.
The CCT expression matches, but the URI doesn't match, while the CCD type is a supertype. This means that we must both expand the CCD type of the abstraction and add an extra tool to it, which is suspicious enough to warrant a warning.
Furthermore, finding the abstraction should be done differently for a workflow than for a concrete tool, because we can work off different assumptions.