|
Last changed Aug 18, 2009 02:50 by Chris Wilper
It's hard to write Service Definitions and Deployments for Fedora.
Don't be sad. This little utility can help: fedora-ezservice-1.0.tar.gz
In a nutshell, EZService generates Fedora Service Definition and Deployment objects from simple XML input files. This technique is much easier to understand (and less error-prone) than creating SDef and SDep FOXML objects by hand. EZService consists of two XSLT stylesheets that do the heavy lifting: EZDef and EZDep EZDefThe EZDef stylesheet transforms a simple "EZDef" document to valid FOXML Service Definition object. Example EZDef XML Input <sdef pid="demo:MyServiceDefinition" label="My Service Definition"> <method name="methodOne"/> <method name="methodTwo"> <user-input name="parm1" optional="true" default="value1"/> </method> <method name="methodThree"> <user-input name="parm1" optional="true" default="value1"> <valid value="value1"/> <valid value="value2"/> </user-input> <user-input name="parm2"/> </method> </sdef> FOXML Service Definition Output <?xml version="1.0" encoding="UTF-8"?> <foxml:digitalObject xmlns:foxml="info:fedora/fedora-system:def/foxml#" VERSION="1.1" PID="demo:MyServiceDefinition"> <foxml:objectProperties> <foxml:property NAME="info:fedora/fedora-system:def/model#state" VALUE="Active"/> <foxml:property NAME="info:fedora/fedora-system:def/model#label" VALUE="My Service Definition"/> </foxml:objectProperties> <foxml:datastream ID="RELS-EXT" CONTROL_GROUP="X" STATE="A" VERSIONABLE="true"> <foxml:datastreamVersion ID="RELS-EXT1.0" MIMETYPE="application/rdf+xml" FORMAT_URI="info:fedora/fedora-system:FedoraRELSExt-1.0" LABEL="RDF Statements about this object"> <foxml:xmlContent> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:fedora-model="info:fedora/fedora-system:def/model#"> <rdf:Description rdf:about="info:fedora/demo:MyServiceDefinition"> <fedora-model:hasModel rdf:resource="info:fedora/fedora-system:ServiceDefinition-3.0"/> </rdf:Description> </rdf:RDF> </foxml:xmlContent> </foxml:datastreamVersion> </foxml:datastream> <foxml:datastream ID="METHODMAP" CONTROL_GROUP="X" STATE="A" VERSIONABLE="true"> <foxml:datastreamVersion ID="METHODMAP1.0" FORMAT_URI="info:fedora/fedora-system:FedoraSDefMethodMap-1.0" LABEL="Abstract Method Map" MIMETYPE="text/xml"> <foxml:xmlContent> <fmm:MethodMap xmlns:fmm="http://fedora.comm.nsdlib.org/service/methodmap" name="N/A"> <fmm:method operationName="methodOne"/> <fmm:method operationName="methodTwo"> <fmm:UserInputParm parmName="parm1" defaultValue="value1" required="false" passBy="VALUE"/> </fmm:method> <fmm:method operationName="methodThree"> <fmm:UserInputParm parmName="parm1" defaultValue="value1" required="false" passBy="VALUE"> <fmm:ValidParmValues> <fmm:ValidParm value="value1"/> <fmm:ValidParm value="value2"/> </fmm:ValidParmValues> </fmm:UserInputParm> <fmm:UserInputParm parmName="parm2" defaultValue="" required="true" passBy="VALUE"/> </fmm:method> </fmm:MethodMap> </foxml:xmlContent> </foxml:datastreamVersion> </foxml:datastream> </foxml:digitalObject> EZDepThe EZDep stylesheet transforms a simple "EZDep" document to a valid FOXML Service Deployment object. Example EZDep XML Input <sdep pid="demo:MyServiceDeployment" cmodel="demo:MyContentModel" label="My Service Deployment"> <impl method="methodOne"> <datastream-input datastream="FOO"/> <url-pattern>(FOO)</url-pattern> </impl> <impl method="methodTwo"> <default-input name="uri" value="$objuri"/> <url-pattern> http://local.fedora.server/fedora/risearch?format=(parm1) &type=triples&lang=spo&query=(uri)+*+* </url-pattern> </impl> <impl method="methodThree"> <default-input name="pid" value="$pid"/> <datastream-input datastream="FOO"/> <datastream-input datastream="BAR"/> <datastream-input datastream="BAZ" object="demo:MyContentModel"/> <url-pattern> http://example.org/service?a=(parm1)&b=(parm2)&c=(parm3) &d=(FOO)&e=(BAR)&f=(BAZ)&g=(pid) </url-pattern> </impl> </sdep> FOXML Service Deployment Output <?xml version="1.0" encoding="UTF-8"?> <foxml:digitalObject xmlns:foxml="info:fedora/fedora-system:def/foxml#" VERSION="1.1" PID="demo:MyServiceDeployment"> <foxml:objectProperties> <foxml:property NAME="info:fedora/fedora-system:def/model#state" VALUE="Active"/> <foxml:property NAME="info:fedora/fedora-system:def/model#label" VALUE="My Service Deployment"/> </foxml:objectProperties> <foxml:datastream ID="RELS-EXT" CONTROL_GROUP="X" STATE="A" VERSIONABLE="true"> <foxml:datastreamVersion ID="RELS-EXT1.0" MIMETYPE="application/rdf+xml" FORMAT_URI="info:fedora/fedora-system:FedoraRELSExt-1.0" LABEL="RDF Statements about this object"> <foxml:xmlContent> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:fedora-model="info:fedora/fedora-system:def/model#"> <rdf:Description rdf:about="info:fedora/demo:MyServiceDeployment"> <fedora-model:hasModel rdf:resource="info:fedora/fedora-system:ServiceDeployment-3.0"/> <fedora-model:isDeploymentOf rdf:resource="info:fedora/demo:MyServiceDefinition"/> <fedora-model:isContractorOf rdf:resource="info:fedora/demo:MyContentModel"/> </rdf:Description> </rdf:RDF> </foxml:xmlContent> </foxml:datastreamVersion> </foxml:datastream> <foxml:datastream ID="METHODMAP" CONTROL_GROUP="X" STATE="A" VERSIONABLE="true"> <foxml:datastreamVersion ID="METHODMAP1.0" FORMAT_URI="info:fedora/fedora-system:FedoraSDepMethodMap-1.1" LABEL="Deployment Method Map" MIMETYPE="text/xml"> <foxml:xmlContent> <fmm:MethodMap xmlns:fmm="http://fedora.comm.nsdlib.org/service/methodmap" name="N/A"> <fmm:method operationName="methodOne" wsdlMsgName="methodOneRequest" wsdlMsgOutput="response"> <fmm:DatastreamInputParm parmName="FOO" passBy="URL_REF" required="TRUE"/> <fmm:MethodReturnType wsdlMsgName="response" wsdlMsgTOMIME="N/A"/> </fmm:method> <fmm:method operationName="methodTwo" wsdlMsgName="methodTwoRequest" wsdlMsgOutput="response"> <fmm:UserInputParm parmName="parm1" defaultValue="value1" required="false" passBy="VALUE"/> <fmm:DefaultInputParm parmName="uri" defaultValue="$objuri" passBy="VALUE" required="TRUE"/> <fmm:MethodReturnType wsdlMsgName="response" wsdlMsgTOMIME="N/A"/> </fmm:method> <fmm:method operationName="methodThree" wsdlMsgName="methodThreeRequest" wsdlMsgOutput="response"> <fmm:UserInputParm parmName="parm1" defaultValue="value1" required="false" passBy="VALUE"> <fmm:ValidParmValues> <fmm:ValidParm value="value1"/> <fmm:ValidParm value="value2"/> </fmm:ValidParmValues> </fmm:UserInputParm> <fmm:UserInputParm parmName="parm2" defaultValue="" required="true" passBy="VALUE"/> <fmm:DefaultInputParm parmName="pid" defaultValue="$pid" passBy="VALUE" required="TRUE"/> <fmm:DatastreamInputParm parmName="FOO" passBy="URL_REF" required="TRUE"/> <fmm:DatastreamInputParm parmName="BAR" passBy="URL_REF" required="TRUE"/> <fmm:DatastreamInputParm parmName="BAZ" passBy="URL_REF" required="TRUE"/> <fmm:MethodReturnType wsdlMsgName="response" wsdlMsgTOMIME="N/A"/> </fmm:method> </fmm:MethodMap> </foxml:xmlContent> </foxml:datastreamVersion> </foxml:datastream> <foxml:datastream ID="DSINPUTSPEC" CONTROL_GROUP="X" STATE="A" VERSIONABLE="true"> <foxml:datastreamVersion ID="DSINPUTSPEC1.0" MIMETYPE="text/xml" FORMAT_URI="info:fedora/fedora-system:FedoraDSInputSpec-1.1" LABEL="Datastream Input Specification"> <foxml:xmlContent> <fbs:DSInputSpec xmlns:fbs="http://fedora.comm.nsdlib.org/service/bindspec" label="N/A"> <fbs:DSInput wsdlMsgPartName="FOO" DSMin="1" DSMax="1" DSOrdinality="false"> <fbs:DSInputLabel>N/A</fbs:DSInputLabel> <fbs:DSMIME>N/A</fbs:DSMIME> <fbs:DSInputInstruction>N/A</fbs:DSInputInstruction> </fbs:DSInput> <fbs:DSInput wsdlMsgPartName="BAR" DSMin="1" DSMax="1" DSOrdinality="false"> <fbs:DSInputLabel>N/A</fbs:DSInputLabel> <fbs:DSMIME>N/A</fbs:DSMIME> <fbs:DSInputInstruction>N/A</fbs:DSInputInstruction> </fbs:DSInput> <fbs:DSInput wsdlMsgPartName="BAZ" pid="demo:MyContentModel" DSMin="1" DSMax="1" DSOrdinality="false"> <fbs:DSInputLabel>N/A</fbs:DSInputLabel> <fbs:DSMIME>N/A</fbs:DSMIME> <fbs:DSInputInstruction>N/A</fbs:DSInputInstruction> </fbs:DSInput> </fbs:DSInputSpec> </foxml:xmlContent> </foxml:datastreamVersion> </foxml:datastream> <foxml:datastream ID="WSDL" CONTROL_GROUP="X" STATE="A" VERSIONABLE="true"> <foxml:datastreamVersion ID="WSDL1.0" MIMETYPE="text/xml" FORMAT_URI="http://schemas.xmlsoap.org/wsdl/" LABEL="WSDL Bindings"> <foxml:xmlContent> <wsdl:definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap" xmlns:soapenc="http://schemas.xmlsoap.org/wsdl/soap/encoding" xmlns:this="urn:thisNamespace" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="N/A" targetNamespace="urn:thisNamespace"> <wsdl:types> <xsd:schema targetNamespace="urn:thisNamespace"> <xsd:simpleType name="inputType"> <xsd:restriction base="xsd:string"/> </xsd:simpleType> </xsd:schema> </wsdl:types> <wsdl:message name="methodOneRequest"> <wsdl:part name="FOO" type="this:inputType"/> </wsdl:message> <wsdl:message name="response"> <wsdl:part name="response" type="xsd:base64Binary"/> </wsdl:message> <wsdl:message name="methodTwoRequest"> <wsdl:part name="parm1" type="this:inputType"/> <wsdl:part name="uri" type="this:inputType"/> </wsdl:message> <wsdl:message name="response"> <wsdl:part name="response" type="xsd:base64Binary"/> </wsdl:message> <wsdl:message name="methodThreeRequest"> <wsdl:part name="parm1" type="this:inputType"/> <wsdl:part name="parm2" type="this:inputType"/> <wsdl:part name="pid" type="this:inputType"/> <wsdl:part name="FOO" type="this:inputType"/> <wsdl:part name="BAR" type="this:inputType"/> <wsdl:part name="BAZ" type="this:inputType"/> </wsdl:message> <wsdl:message name="response"> <wsdl:part name="response" type="xsd:base64Binary"/> </wsdl:message> <wsdl:portType name="portType"> <wsdl:operation name="methodOne"> <wsdl:input message="this:methodOneRequest"/> <wsdl:output message="this:response"/> </wsdl:operation> <wsdl:operation name="methodTwo"> <wsdl:input message="this:methodTwoRequest"/> <wsdl:output message="this:response"/> </wsdl:operation> <wsdl:operation name="methodThree"> <wsdl:input message="this:methodThreeRequest"/> <wsdl:output message="this:response"/> </wsdl:operation> </wsdl:portType> <wsdl:service name="N/A"> <wsdl:port binding="this:binding" name="port"> <http:address location="LOCAL"/> </wsdl:port> </wsdl:service> <wsdl:binding name="binding" type="this:portType"> <http:binding verb="GET"/> <wsdl:operation name="methodOne"> <http:operation location="(FOO)"/> <wsdl:input> <http:urlReplacement/> </wsdl:input> <wsdl:output> <mime:content type="N/A"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="methodTwo"> <http:operation location="http://local.fedora.server/fedora/risearch?format=(parm1)&type=triples&lang=spo&query=(uri)+*+*"/> <wsdl:input> <http:urlReplacement/> </wsdl:input> <wsdl:output> <mime:content type="N/A"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="methodThree"> <http:operation location="http://example.org/service?a=(parm1)&b=(parm2)&c=(parm3)&d=(FOO)&e=(BAR)&f=(BAZ)&g=(pid)"/> <wsdl:input> <http:urlReplacement/> </wsdl:input> <wsdl:output> <mime:content type="N/A"/> </wsdl:output> </wsdl:operation> </wsdl:binding> </wsdl:definitions> </foxml:xmlContent> </foxml:datastreamVersion> </foxml:datastream> </foxml:digitalObject> Which would you rather write? I'm sure someone will come up with a good way of creating these visually. But I suspect that won't happen 'till Fedora's SDefs/SDeps become simpler and more REST-friendly. Until then, there's EZService.
Last changed Apr 16, 2009 00:09 by Chris Wilper
Paul was describing how Mulgara Resolverswork today and Aaron pointed out that it may be possible to plug MPTStorein as a resolver. This is interesting because it would allow one to use Mulgara's higher-level query capabilities (e.g. SPARQL) on top of MPTStore. Additionally, for Fedora this would allow us to continue offering triplestore engine choice while working directly against the Mulgara interfaces vs going through Trippi. Note however, that when using XA1.x (Mulgara's current storage engine), getting good throughput for lots of small writes would still require some sort of buffering layer. Long-term, we believe XA2 will remove the requirement to do buffering "above" Mulgara for good write throughput. XA2 is designed to make newly-committed changesets immediately visible, then merging them in the background. Key Mulgara Interfaces
Key MPTStore InterfacesQuestions
Last changed Mar 30, 2009 17:24 by Bill Branan
I recently posted some screenshots of the new web-based Fedora administrative GUI. Take a look here: Web Admin Screenshots
Last changed Feb 22, 2009 19:19 by Daniel Davis
I've recently made a few significant changes to the FCREPO Tracker and thought it would be good to share them here. Some of this info will eventually work it's way into the Developer's Wiki, but for now it's a blog post. Improvements
Issue Lifecycle
ERROR: You are using a new version of the Gliffy Plugin for Confluence, but have not purchased a new license. To create new diagrams, either revert to an older version of the plugin, or purchase an upgrade license ReceivedAll new issues begin in this state. If it's clearly in scope for the project, it will be moved to "Open" by one of the committers. If it's not in scope or is a duplicate, etc, it will closed. If an issue remains in the recieved state for a longer than a couple weeks, it means we think it deserves more discussion before making a determination. OpenIssues in this state are in scope for a future release. The target release may not have been determined yet. Generally higher-priority items will worked on first. The committers will take our best guess on the initial priority of issues, but the priority may be increased or decreased based on input we receive (votes, comments) from the community. Issues that are not yet assigned can be worked on by anyone in the community. Attaching a good quality patch to an open issue is the best way to vote In ProgressThis state means a developer is currently working on the issue. Small issues will usually bypass the review step and be Closed (and resolved as "Fixed") once the changes are committed to trunk and pass automated tests. Larger issues will be moved to the "In Review" state at the discretion of the developer. In ReviewThe assignee has asked someone to take a look at the solution before closing the issue. ReopenedThe issue was thought to be resolved, but isn't. ClosedThe issue has been resolved. Possible resolutions are:
Last changed May 08, 2009 09:57 by Bill Branan
I just posted a mockup of how I'm thinking the new Administrator GUI may look/work. Take a look, and add a comment letting me know what you think.
Last changed Nov 10, 2008 22:51 by Chris Wilper
At the on-site last week, we had some additional discussion of the "Service Ladder" idea. Notes and images from the board can be found at the On-Site Nov 3-7 Meeting Notes page.
Last changed Oct 31, 2008 16:25 by Bill Branan
Fedora 3.1 has been released! In other news, I'm working up a plan for an application called FedoraShare. This will be a front-end application for Fedora which integrates with content that is stored on other sites around the web and allows users to tag, comment on, and create relationships between any content, whether it be stored in Fedora or not. For more info, take a look at my write up and screenshot mockups.
Last changed Oct 17, 2008 13:53 by Bill Branan
Other than various activities surrounding the 3.1 release coming up next week, my main work of interest this week was doing a review of Open Laszlo and writing up my thoughts on Flex and Open Laszlo so far. The end goal of this investigation is to get started on a new web-based Administrator GUI for Fedora. Trippi has been updated to include the latest Mulgara release (2.0.6). Notably, this latest release of Mulgara includes updates to the storage layer (XA 1.1) which improves performance while using less space and fewer files. See the Mulgara release notes for more details. I've been a bit remiss about actually creating file releases for Trippi on Sourceforge when new versions have been tagged, but this version has had a proper release. Fedora trunk and the maintenance branch have also been updated, so 3.1 and 2.2.4 (due later next week) will both include Trippi 1.4.1 (and thereby Mulgara 2.0.6).
Last changed Oct 13, 2008 13:07 by Bill Branan
The first half of this week I spent with Chris at MIT sitting in on the DSpace 2.0 architecture design meeting. In this session, they were focused primarily on determining the high-level services necessary to support the next version of DSpace.
The last half of the week was spent finishing up tasks prior to the 3.1 release.
Last changed Oct 10, 2008 12:15 by Edwin Shin
I've released version 0.1 of the Fedora unAPI HTTP Service to Sourceforge. No major changes since the original prototype, except for the addition of a FedoraPmhResolver. In contrast to the FedoraResolver, the FedoraPmhResolver relies on Fedora's OAI service to describe the available formats for Fedora objects. Depending on the desired use, one may be more suitable than another. The FedoraResolver is more flexible and can support arbitrary formats, but it requires Fedora 3.x. The FedoraPmhResolver should work with any version of Fedora that supports OAI-PMH (although I've only tested it with 3.0). Similarly, I expect the DSpacePmhResolver should work with any version of DSpace that support OAI-PMH, but I've only tested it against 1.5.1.
Last changed Oct 08, 2008 09:37 by Chris Wilper
Bill and I are leaving Boston today after a good set of meetings with the DSpace folks. I'll be hitting the road shortly, but I wanted to get some thoughts out on what we're calling "The Ladder" for lack of a better term. The concept of the ladder is this: Assuming we have Akubra, what are the next "rungs" of agreement in a shared persistence model? We played with the idea of different levels, starting with the purely structural, and moving carefully up into semantics. At Level 0, you have Blobs with Ids. This is Akubra. I should point out that this ordering was a result of brainstorming, and we did not attempt to flesh out the details for each level. But it gave us a sort of strawman to frame the discussion. Here's my first attempt at refinement after sleeping on it. Two key goals:
Level 0Blobs with Ids and readonly properties (size, minimal others). Level 1Entities with readonly + writable relationships and properties. Entities optionally have content (represent bitstreams aka Blobs). Level 2Entities with everthing in level 1, plus key inferred (read-only) relationships. A big requirement here is to support two-way links for whole-part relations. Might also include transitive relationships. It's possible to infer such relationships from what's expressed in level 1 and a set of inference rules. Level 3Higher-order repository domain objects. The concept of a metadata entity relating to content entity would be represented here.
Last changed Oct 06, 2008 10:27 by Chris Wilper
Last changed Oct 03, 2008 18:15 by Chris Wilper
Just wanted to share this paper, in which the term "spanning layer" was coined. Interoperation, Open Interfaces, and Protocol Architecture - David D. Clark Interesting stuff.
Last changed Oct 03, 2008 17:58 by Bill Branan
Here's what I've been up to lately:
|
- This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.