Whilst the TaskFactory pattern is very similar to the DescriberFactory pattern, in this case I don't think that we want to pipe one TaskActor into the other - I think that we always want to match one task to one action (?)
Despite this we actually always expect a Task to have multiple RDF types, for example our task Transit is a sub-type of Task, which itself is an rdfs:Class
I think that reasoning which the lowest child class is in the hierarchy (the "most specific") would be over-engineering when we can just add a mandatory property onto mudLogic:Task, the mudLogic:taskImplements, which can have only one value
Whilst the TaskFactory pattern is very similar to the DescriberFactory pattern, in this case I don't think that we want to pipe one TaskActor into the other - I think that we always want to match one task to one action (?)
Despite this we actually always expect a Task to have multiple RDF types, for example our task
Transitis a sub-type ofTask, which itself is anrdfs:ClassI think that reasoning which the lowest child class is in the hierarchy (the "most specific") would be over-engineering when we can just add a mandatory property onto
mudLogic:Task, themudLogic:taskImplements, which can have only one value