Hi, Yes, we offer the SWORD interface on all Open Repository hosted repositories - and we have clients that are working with it to develop systems to populate the their repositories with content.
Which brings us to an interesting limitation of the reference implementation, that I would like to see some thought and discussion on. Currently, the SWORD interface accepts metadata in an EPrints DC Xml document, conforming to the SWAP profile. By only implementing the SWAP profile, then there is only a limited amount of metadata that is recognised and ingested. For our deployment (and client's needs), this was insufficient. We needed a way of ingesting metadata for any field that is registered in the repository. What I came up with was a way of representing the available metadata fields as propertyURIs in the EPDCX document. This would allow extended data to be passed to the repository, and still have a graceful fallback where the extra metadata isn't understood - or at least allow for the package to be easily retargetted. The URI encoding is a very simple strategy of using 'http://openrepository.com/metadata/<SCHEMA>/<ELEMENT>/<QUALIFIER>' ie. http://openrepository.com/metadata/dc/description/abstract This was a simple way of letting our clients target *any* metadata schema/field that has been registered, and can be handled in a single small XSL transformation in the ingest: <xsl:if test="starts-with(./@epdcx:propertyURI,'http://openrepository.com/metadata/')"> <xsl:variable name="SchemaElementQualifier" select="substring-after(./@epdcx:propertyURI,'http://openrepository.com/metadata/')" /> <xsl:variable name="Schema" select="substring-before($SchemaElementQualifier,'/')" /> <xsl:variable name="ElementQualifier" select="substring-after($SchemaElementQualifier,'/')" /> <xsl:variable name="Element" select="substring-before($ElementQualifier,'/')" /> <xsl:variable name="Qualifier" select="substring-after($ElementQualifier,'/')" /> <xsl:element name="dim:field"> <xsl:attribute name="mdschema"><xsl:value-of select="$Schema" /></xsl:attribute> <xsl:choose> <xsl:when test="normalize-space($Qualifier)"> <xsl:attribute name="element"><xsl:value-of select="$Element" /></xsl:attribute> <xsl:attribute name="qualifier"><xsl:value-of select="$Qualifier" /></xsl:attribute> </xsl:when> <xsl:otherwise> <xsl:attribute name="element"><xsl:value-of select="$ElementQualifier" /></xsl:attribute> </xsl:otherwise> </xsl:choose> <xsl:value-of select="epdcx:valueString"/> </xsl:element> </xsl:if> A quick and very simple solution to a problem that was biting us in the short term. Question is, would it be useful to the community to crystalise a strategy for passing information beyond that defined by the SWAP profile? For example, take the above strategy, but declare a dspace.org URI namesspace for the propertyURI encoding? And there potentially is a wider question of an automated discovery of the available metadata fields understood by a repository. G On 22/01/2009 09:50, Timo Aalto wrote: > Hi all, > > I'd like to know if the SWORD implementation for DSpace 1.5.x is being > used anywhere in a production environment. Are there any known bugs or > other issues with it? I'm asking this because I'm researching the > possiblility of having our university's forthcoming Current Research > Information System to implement SWORD for interacting with our DSpace > repository. This would seem to be a better approach than further > developing an existing DSpace-specific connector that the CRIS vendor > now offers. > > Thanks in advance for any input, > > T > > -- > Timo Aalto > Planning Officer > University of Helsinki Library Coordination Unit > timo dot j dot aalto at helsinki dot fi > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > > > ------------------------------------------------------------------------ > > _______________________________________________ > DSpace-tech mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/dspace-tech ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
