Page History

...

If so, then the separate interface definitions for the SDef and SDep triple generators are probably unnecessary. Instead, we may have an application context for triple generation, one for service definition, and another for service resolution?

Returning to ModelBasedTripleGenerator as an example:

Code Block


 <beans>
  <bean id="ModelBasedTripleGenerator"
   class="org.fcrepo.server.resourceIndex.ModelBasedTripleGenerator">
   <constructor-arg>
     <map>
       <entry key="info:fedora/fedora-system:ServiceDefinition-3.0">
         <bean class="org.fcrepo.server.resourceIndex.ServiceDefinitionTripleGenerator_3_0"></bean>
       </entry>
       <entry key="info:fedora/fedora-system:ServiceDeployment-3.0">
         <bean class="org.fcrepo.server.resourceIndex.ServiceDeploymentTripleGenerator"></bean>
       </entry>
       <entry key="info:fedora/fedora-system:ContentModel-3.0">
         <bean class="org.fcrepo.server.resourceIndex.ContentModelTripleGenerator_3_0"></bean>
       </entry>
       <entry key="info:fedora/fedora-system:FedoraObject-3.0">
         <bean class="org.fcrepo.server.resourceIndex.FedoraObjectTripleGenerator_3_0"></bean>
       </entry>
     </map>
   </constructor-arg>
  </bean>
</beans>

This works because the triple generators are re-usable. (Example configTo implement service-aware readers, the model driven behaviors need to provide a factory method of some kind.

(service-aware reader example)

(model-driven behavior example)

4.x CMA Sketch

More to come, but presumably moves away from any WSDL specification as the default type.

Versions Compared

Old Version 13

New Version 14

Key

4.x CMA Sketch