Hi Scott, Thanks for alerting us to this. I'll have a chat to Phil and Simon about it.
Cheers, Stuart On 14/10/2011, at 11:13 PM, Scott Wilson wrote: > CEN has been presented with a draft Workshop Agreement on Interoperability of > Registries. The draft mentions SPI for publishing but not SWORD. > > Unfortunately, there is only until next Wednesday to submit any revisions. > > Would someone from SWORD be willing to liaise with CETIS to get a description > of SWORD into the draft? > > I've pasted below the relevant section; a section 6.3.2 covering SWORD in > similar detail would be required. > > If you're interested, please contact Phil and Simon: > > Phil Barker <phil.bar...@hw.ac.uk> > Simon Grant <asim...@gmail.com> > > S > > > 6.3. Publish > One of the requirements of a registry is that it should be possible to > add/delete repositories to a registry and to update collection descriptors in > a registry. > 6.3.1. The Simple Publishing Interface (SPI) > The Simple Publishing Interface (SPI) is used to push digital resources or > their metadata into a repository [CWA16097 2010, Ternier 2010]. SPI makes > relatively few assumptions about the resources and metadata that can be > published. Therefore, it is a good candidate for being used in the context of > a registry. The UML class diagram in Figure 6 illustrates these assumptions. > Figure 6: Digital Resources and their Metadata. Reproduced from [CWA16097 > 2010] > Every resource must have an identifier and may have an associated filename. A > resource can be described by zero or more metadata instances. Every metadata > instance describes exactly one resource. It must have a metadata identifier > that identifies the metadata instance itself and must have the resource > identifier of the resource it describes. > SPI does not assume that a resource and its metadata need to be published in > the same repository. As a consequence, SPI supports four operations: > • • • • > Submitting (publishing) a resource to a repository/registry, Deleting a > resource from a repository/registry, Submitting a metadata record to a > repository/registry, and Deleting a metadata record from a > repository/registry. > There is no explicit operation to update a resource or a metadata instance. > An SPI binding can offer this functionality out-of-band as an SPI extension, > or deleting the resource and re-publishing it may provide update > functionality. > Besides extending the specification, an SPI binding may also omit operations. > Similarly, an implementation of a binding can (if the binding allows this) > omit operations. Depending on the content managed by a repository (i.e., > resources only, metadata only, or resources and metadata), a repository can > support different combinations of these operations. For instance, a > referatory will only offer operations to submit and delete metadata and omit > the operations to manage resources. > Submitting a resource involves sending a binary stream to the target. > Depending on the binding that is used, this byte-stream can be encoded in > various ways. SPI supports two ways of submitting a resource to a repository: > "by-value" and "by-reference". > In by-value publishing, the resource is directly embedded (after encoding) in > a message sent to a repository. In by-reference publishing, the message sent > to the repository only contains a reference (e.g., a URL) to thePage 19 Draft > CWA NNNNN > submitted resource. It is then the responsibility of the repository to use > this reference to retrieve the resource and store it. > By-value publishing is useful for a standalone application (e.g. an authoring > tool), which is generally not associated with a web server from which a > repository can obtain a resource. Embedding a resource in a message passed to > the repository is beneficial for publishing a resource from a desktop > application. It lowers the threshold for publication because uploading the > resource to a third party component that hosts the referenced resource is > unnecessary. By-reference publishing is particularly suited to publishing > large resources, since embedding large files into a single message may cause > degraded performance, resulting in a need for a distinct method (e.g., FTP, > HTTP, SCP, etc.) for a large resource. > The submission of a metadata instance to a repository is similar to the > submission of a resource by-value. The metadata instance itself is embedded > in a message sent to the repository. Since multiple metadata instances can > describe a single resource, the operation specifies the identifier for the > metadata instance and the identifier of the resource it describes. Publishing > an additional metadata instance for a resource can be realized by publishing > it using a different metadata identifier. > SPI supports two delete operations, one for resources and one for metadata. > These operations are straightforward. The identifier of the object (resource > or metadata instance) to delete is submitted to the repository that then > completes the deletion. > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2d-oct_______________________________________________ > Sword-app-techadvisorypanel mailing list > Sword-app-techadvisorypanel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ Sword-app-techadvisorypanel mailing list Sword-app-techadvisorypanel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
