Looking at the SOFA data model, it occurs to me that I didn't properly specify how match type descriptions were created and/or stored. Initially, I assumed a known URI, which was enough for the compatibility filters (i.e. just find annotations targeting a known URI), but I don't think is enough to drive the UI. E.g. I assume the match description contains a label that can be displayed in the match type selection UI.
This would require that the match description is pre-stored at a known URI. But in the spiurit of separating the compatibility annotation agent from the remixer logic, I think it should be data that is created and stored, or known to, by the compatibility agent itself. This aspect seems to be under-specified.
I'd be interested to hear what the current implementation is doing.
I can imagine a number of approaches to this:
The match description is already stored and dereferencable on the web somewhere, and the agent knows where that somewhere is, and simply uses that URI. (It could even be a data: URI.) This fits with the model as specified, but I wonder if it might prove inflexible at some point in the future [1].
use a predefined URI as originally, but don't attempt to dereference it; i.e. it a pure identifier. Then store descriptive information in the match service container (rdfs:label, etc.). I imagine this would involve a change to SOFA remixer logic.
Introduce a new container for target descriptions, and reference it specifically from the top-level container. I.e. like sofa:working_sets. Then have the agent look for an existing container and create a new one if it doesn't already exist. This requires some additional logic in the agent, and possibly a new internal interface to search within the content of annotation targets. It would allow the remixer system to run offline from a single local LDP container service. It does not preclude option 1 (but doing that would lose the offline working option).
[1] I know, YAGNI, etc. But I'm, already thinking about another scenario [2] where a similar problem arises and I'm not yet sure if the simple approach would work there. So am looking for a generic approach that can serve multiple purposes.
[2] this would be ensemble descriptions, using a mechanism that could generalize to any session-level configuration option.
Looking at the SOFA data model, it occurs to me that I didn't properly specify how match type descriptions were created and/or stored. Initially, I assumed a known URI, which was enough for the compatibility filters (i.e. just find annotations targeting a known URI), but I don't think is enough to drive the UI. E.g. I assume the match description contains a label that can be displayed in the match type selection UI.
This would require that the match description is pre-stored at a known URI. But in the spiurit of separating the compatibility annotation agent from the remixer logic, I think it should be data that is created and stored, or known to, by the compatibility agent itself. This aspect seems to be under-specified.
I'd be interested to hear what the current implementation is doing.
I can imagine a number of approaches to this:
The match description is already stored and dereferencable on the web somewhere, and the agent knows where that somewhere is, and simply uses that URI. (It could even be a data: URI.) This fits with the model as specified, but I wonder if it might prove inflexible at some point in the future [1].
use a predefined URI as originally, but don't attempt to dereference it; i.e. it a pure identifier. Then store descriptive information in the match service container (
rdfs:label, etc.). I imagine this would involve a change to SOFA remixer logic.Introduce a new container for target descriptions, and reference it specifically from the top-level container. I.e. like
sofa:working_sets. Then have the agent look for an existing container and create a new one if it doesn't already exist. This requires some additional logic in the agent, and possibly a new internal interface to search within the content of annotation targets. It would allow the remixer system to run offline from a single local LDP container service. It does not preclude option 1 (but doing that would lose the offline working option).[1] I know, YAGNI, etc. But I'm, already thinking about another scenario [2] where a similar problem arises and I'm not yet sure if the simple approach would work there. So am looking for a generic approach that can serve multiple purposes.
[2] this would be ensemble descriptions, using a mechanism that could generalize to any session-level configuration option.