Sapere Aude!

Presentation: Backporting DSpace Services #dsug09

2009-10-18T00:18:00.001-07:00

I just recently completed a presentation on the work @mire has done to backport DSpace Services to the 1.6.0 release that is planned for release sometime before the end of the year. As I haven't received any request for the slides, I've placed them on slide-share.

Dsug09 Services

View more presentations from Mark Diggory.

While one always cringes at viewing oneself in video, I'll post the video stream as well for those that are interested in working with the dspace services framework.

User Group Meeting Site: http://dsug09.ub.gu.se/index.php/dsug/dsug09
Crowdvine: http://dsug09.crowdvine.com/
Video Streaming: http://bambuser.com/channel/dsug09

Open Repositories DSpace User Group Presentations

2009-05-27T22:15:00.001-07:00

Michele Kimpton recently aggregated together this years Open Repositories DSpace User Group Presentations into one post for the community. These were posted on the Georgia Tech OR09 presentation website. Below is a reposting of those presentations. Congratulations to all the presenters on a fine conference.

May 20th, 2009

Session One

DuraSpace - Michele Kimpton and Sandy Payette

http://presentations.dlpe.gatech.edu/or09/or09_052009_1/index.html

Session Two

DSpace Technology Overview - Bradley McLean

Repository Software Technical Update with Chris Wilper - Chris Wilper

http://presentations.dlpe.gatech.edu/or09/or09_052009_2/index.html

Session Three

2.0 Demonstration - Ben Bosman

http://presentations.dlpe.gatech.edu/or09/or09_052009_3/index.html

Session Four

XMLUI Modularity in DSpace 1.5 & 2.0 - Mark Diggory

DSpace 1.5 Modifications: A Technical Overview - Elliot Metsger

DSpace 2 Service Manager Framework - Aaron Zeckoski

http://presentations.dlpe.gatech.edu/or09/or09_052009_4/index.html

Session Five

Designing and Implementing a Learning Object Repository - William E Moen

Using DSpace as a Disciplinary Data Repository - Ryan Scherle

Introducing Vireo - ETD Submittal and Management for DSpace - Adam

Mikeal, Scott Phillips, John Leggett, Mark McFarland

The Sustainability, Preservation, Accessibility of Internal and

External Communities by Universities - Jeffrey Trimble and Salvador

Barragan

http://presentations.dlpe.gatech.edu/or09/or09_052009_5/index.html

May 21st, 2009

Session One

Depth Customization of DSpace - S.K. Vijaianand and V.D. Shrivastava

http://presentations.dlpe.gatech.edu/or09/or09_052109_1/index.html

EIAH's Experience in Localization and Customization of DSpace - Emad

Khazraee, Saeed Moaddeli and Hamed Malek

http://presentations.dlpe.gatech.edu/or09/or09_052109_2/index.html

The Myth of Federated Searching - OhioLINK Digital Resoursce Commons

Team

http://presentations.dlpe.gatech.edu/or09/or09_052109_3/index.html

Session Two

Making DSpace 1.5 Your Own: Customizing Via Overlays - Tim Donohue

http://presentations.dlpe.gatech.edu/or09/or09_052109_4/index.html

DSpace Global Outreach Committee Update - Valorie Hollister

http://presentations.dlpe.gatech.edu/or09/or09_052109_5/index.html

DSpace 2.0 Entities and Service Domains.

2009-05-23T14:42:00.001-07:00

This last weeks OR09 meeting unleashed a number of new epiphanies around DSpace 2.0. I feel these realizations should lead us to the next step in way we represent entities like DSpace Items.

One of these ideas has to do with the recognition that an Item is actually a "View" or a "Join" of properties from separate functional areas such as "content", "history", "policy", and "presentation". Here are a few examples of those areas.

1.) Content: An underlying store in DSpace might be JCR, Fedora, DSpace, and s3. Each of these maintain a separate model expressing content their domain. Fedora (Fedora Objects and Datastreams), JCR (JCR Nodes, JCR Properties, JCR References), DSpace (Collections, Communities, Items, Bundles, Bitstreams, etc).

2.) History: Each of these above storage systems presents Versioning, History or Provenance differently in its above ER (Entity Relationship) model. While the Content domain may provide a representation of that versioning history, there is still the requirement of a separate service layered (or not layered) on top of that to work with the at Versioning model.

3.) Policy: Certainly each of these expresses a set of policy information, which is generally managed in a separate service or layer on top of the Entities expressed therein.

4.) Presentation: Once you have these expressed, external tools will seek to have varying "expressions" of the previous 3 areas that are specific to a particular domain/tool (HTML, AJAX/Web 2.0, OAI-PMH, LOD, ATOM/APP) Some of these various communities seek to constrain what out of the previous 3 areas can be expressed within their transmissions.

I feel that being at the nexus of all these functional domains, DSpace 2.0 has an opportunity to be something very powerful. If we can recognize that the "presentation" of any DSpace 2.0 Entity is a JOIN of the data from each of these areas, and that we have different "Services" responsible for expressing, accessing and persisting that "domain specific" data, then its clear that for any one entity in the DSpace model that we actually have N possible domain specific representations of an Entity expressed.

Content: Content in an underlying stores model on a per Entity basis.
History: Provenance, Versioning, and Change History Trail in Harmony per Entity.
Policy: Access Control and other Policy rules per Entity.
Presentation: Rendering details specific to a serialization of the Entity.

For much of the week I had been battling if we would want to provide Access Control configurability on a per property basis in DSpace 2.0, such that one would set explicit access rights on each property (regardless of its "functional use") in an Entity, it seemed that it could get very unwieldy, bloated and slow as the store grew. As an alternative, I was exploring mediating access control for only Entities on a per Service basis. Given the above analysis, I'm beginning to think this is the more reasonable approach.

To give an example, an Item might have a set of System properties, Descriptive properties, Provenance properties, and Policy controls; all stored in separate services. In DSpace 1.x provenance was stored directly in the metadata table (I.E. the Content Domain). Capturing changes on the "Content Domain" of the Item becomes difficult to mediate rights on because the changes themselves get encoded as changes in the "Content Domain" of the Item.

Work was ongoing at MIT by Mackenzie Smith to separate out that change history into an independent service based on a "history" triple-store. This is actually the right direction we should be going in for DSpace 2.0 and I think we may now see the correct path to integrate not just the work completed in the Pledge project into DSpace 2.0, But also possibly some of the significant work completed in last years Google Summer of Code on Fedora integration and Versioning of DSpace Items.

Who's going to pet the shark first?! Are you kidn' me?! No way!

2009-05-19T17:14:00.001-07:00

Pacific barrier Reef

2009-05-19T15:35:00.001-07:00

Dinner time?

2009-05-19T15:10:00.001-07:00

Georgia Aquarium

2009-05-19T14:35:00.001-07:00

OR09

Google Announces Support for RDFa Rich Snippets

2009-05-14T16:53:00.001-07:00

Everyone is carrying on about Google supporting RDFa...

http://google.com/support/webmasters/bin/answer.py?hl=en&answer=99170

http://rdfa.info/2009/05/12/google-announces-support-for-rdfa/

http://radar.oreilly.com/2009/05/google-announces-support-for-m.html

For DSpace, this means we need to pay attention to semantic markup in our Items. I think for DSpace 2.0 this will be "key". DSpace 2.0 Entities align cleanly with RDF Resources. It will be very exciting to see how this synergy gives rise to publishing and describing our content in as much detail (or in as little detail) as we like! Pay attention to our presentation at the upcoming OR09 Conference next week to see how @mire and the DSpace Foundation have partnered to get DSpace 2.0 off the ground and ready for this brave new world.

Moving the DSpace SVN Repository to Oregon State University Open Source Lab.

2009-05-14T14:51:00.001-07:00

After over 6 months of working closely with the Oregon State University Open Source Lab (many thanks to Jeff Sheltren, Rudy Grigar, and Lance Albertson of OSUOSL) we've migrated the DSpace S.F. SVN repository to a custom CentOS Virtual Server at OSL.

This move is to spearhead an initiative to consolidate and scale the three open source SVN repositories we maintain into one repository under one roof. The primary goal being to create an environment where our community can begin to scale, delegate access rights, and management responsibilities of specific portions of our codebase. Something we cannot attain with existing SourceForge and GoogleCode free resources. The DSpace community is a diverse, international and growing and we have a need for scalable solution that will grow with us in both Access Control and performance. OSL became an obvious choice for both its personal approach to hosting Open Source projects and its position in the academic community on Internet2. OSL provides excellent hosting solutions for many Open Source Initiatives!

From this point forward http://scm.dspace.org/svn/repo will house the contents of the following repositories:

http://dspace.svn.sf.net/svnroot/dspace
http://code.google.com/p/dspace-sandbox

Eventually we will consider adding the contents of http://code.google.com/p/dspace-gsoc if it is deemed relevant (which it may seem with our recent GSoC acceptances). Please come and comment if you have an interest in participating in the community on our listservs.

YOU CAN GET $4500 FOR DOING "THAT"?!!!

2009-03-20T08:13:00.001-07:00

The DSpace Foundation has registered with Google to participate in this years Google Summer of Code internship program. The DSpace community participated the last two years, completing 4-5 successful and interesting projects each year. Each of these projects has brought value to our community at large.

What are the requirements for participating in GSoC 2009!?? Find out here (professors, show this to your students)...

(ok, kinda dry, but gets to the point right away, "Google Will Give You Money!").

And more propaganda here!!!

The purpose of participation is to (1) promote involvement of new students as open source developers within the DSpace Community, (2) provide opportunities for existing community members to lead within the community as mentors, and (3) build some exciting new add-ons and prototypes for DSpace along the way, .

We would like to encourage "all community members" to post their ideas for projects on the wiki: Google_Summer_of_Code_Ideas. To see ideas from 2008 for reference: Summer_of_Code_Ideas_2008

We need to get as many ideas posted by MARCH 24th, as this is when the application period begins for students (applications are accepted until Fri, April 3, 12pm PST) If you are interested in participating as a student If you would like to be a mentor on the project you proposed, are an active developer in the community and keenly interested in leading a student through a software development project, join the community and apply in the GSoC 2009 application as a mentor for the DSpace project.

Get excited and join in on the fun!

The Semantic Web will not be Open Access!

2008-11-27T09:47:00.001-08:00

Recently, I followed a search on Linked Open Data, only to find its source to be a series chapter from a resource published by Springer. I was frustrated to find that I would have to pay for this book because my university's subscription to Springer does not include such special cases. I'll admit it was a let-down to be seeking out research material on Linked Open Data, only to find it in a closed subscription based publisher. I had a "light-bulb" moment upon this discovery that the semantic web will not be a utopia of Open Access. It will more simply mirror the current subscription models found in Web 1.0 because researchers will continue to publish work with commercial entities such as Springer, and these publishers will continue to grow and evolve. I speculate that as soon as the semantic web technologies achieve a significant footprint in the open access domain, they will be adopted by publishers, not to make their systems open, but to retain their market share by making their systems easier to integrate into global and institutional search engines. Not that this is necessarily a "bad" reuse of the technology. Just that, for the next generation of the web to be as successful as the first requires buy-in from the commercial world. It is inevitable that the same business models present today in the web will permute into the next generation. I've found the work of Tim O'Reilly very inspirational and believe he has a similar viewpoint on the economic and publishing models that will persist into the web's future.

Reflections from JA-SIG 2008 St. Paul DSpace / Fedora BoaF

2008-10-02T21:08:00.001-07:00

It is intriguing to see how others perceive of the things that come out of ones mouth. This is a great little commentary by Jason Stirnaman on the the JA-SIG BoaF we had around the Fedora table chatting about the niches that Fedora and DSpace fill.

http://wire.jstirnaman.com/2008/04/30/ja-sig-2008

Decomposing the DSpace Data Model

2008-09-30T22:41:00.001-07:00

DSpace Items in RDF

Lately I’ve been carrying on about how the DSpace Data Model can be expressed in RDF as an abstraction composed wholly of RDF Statements. The driving point that I’ve been working to get across to the community is that RDF is a simple mechanism for expressing metadata and the links between that metadata and the content it represents. I will create a small example that shows its power. We'll start with an Item with a Bitstream and some metadata:

In this current representation we have created a simple DSpace Item, but it is a Complex Digital Object that is comprised of an abstraction we call and “Item” and two concrete files we have attached to it (called Bitstreams). The Item is a “Container of Files” with metadata attached. In DSpace 1.X, we currently have no way to associate metadata with the Bitstreams because the current fields that are supported are hard-coded as database columns, while the Items attached metadata is in a table that breaks it up into:

While this is not how it really looks in the db (as that is comprised of multiple tables attached by keys) for practical purposes we will talk as if it is just one table. The above table shows us what is referred to as a “Triple” of data.

<info:hdl/1234.5/67890> dc:title “My Item”

The <> are a reference to a “Resource” or “URI” that represents the “subject” of this statement. The “My Item” is most obviously a String value, in RDF this is referred to as a “Literal” and finally between them is a “Predicate” or “Property” asserting a relationship between the two. Grammatically in this case we are saying: The dc:title of <XXX> is “My Item”.

We can apply the same logic to the other properties in the Item, but what do we do with the “Bitstreams”. We certainly have much to say about them, perhaps they are “subjects” we want to make some important statements about. And so we can using the above syntax:

<info:hdl/1234.5/67890/1> dspace:name “file_1.ext”
<info:hdl/1234.5/67890/2> dspace:name “file_2.ext”

Now we’ve made some descriptive statements about each resource in our DSpace Item, but we still do not know much about how they are related to one another. It would be nice if there were statements we could make about how DSpace Items and Bitstreams related to one another. Luckily, in RDF we can do just that if, instead of placing a “Literal” value at the end of the statement, we just place a reference to another resource:

<info:hdl/1234.5/67890> dspace:hasBitstream <info:hdl/1234.5/67890/1>
<info:hdl/1234.5/67890> dspace:hasBitstream <info:hdl/1234.5/67890/2>

Likewise, we can make similar assertions for each Bitstream about its parent Item

<info:hdl/1234.5/67890/1> dspace:isPartOfItem <info:hdl/1234.5/67890>
<info:hdl/1234.5/67890/2> dspace:isPartOfItem <info:hdl/1234.5/67890>

We’ve said quite a bit at this point, I think its time for a full example to allow you to see everything at once in N3, I’ll use a representation that allows me to group the statements by their Subjects:

    <info:hdl/1234.5/67890>
        dc:title “My Item”;
        dspace:hasBitstream <info:hdl/1234.5/67890/1>;
        dspace:hasBitstream <info:hdl/1234.5/67890/2>.

    <info:hdl/1234.5/67890/1>
        dspace:isPartOfItem <info:hdl/1234.5/67890>;
        dspace:name “file_1.ext”.

    <info:hdl/1234.5/67890/2>
        dspace:isPartOfItem <info:hdl/1234.5/67890>;
        dspace:name “file_2.ext”.

Now, if I wanted to come back to representing these relationships in a Database table, It Might look something more like:

The above is the basis for most RDF triple-stores, they all try to do things to optimize the ability to store and search across the following space, but for the most part, they all start from this point of storing Triples that describe the relationships between Subjects, Predicates and Objects.

I feel the above representation is a very powerful one, and represents how one can attach not only descriptive metadata statements to any Subject in DSpace (Communities, Collections, Items, Bundles, Bitstreams, BitstreamFormats, EPeople, Groups, and Policies) but to also express how each of these subjects relates to one another.

Ultimately, this begs the question, “Why does the subject of one of these statements even have to be one of these DSpaceObject resources?” and my opinion is that in this strategy, we can describe metadata relationships that have little to do with the DSpaceObject hierarchy itself. For instance, we could state something like:

    <some/identifier>
        a frbr:Work;
        dcterms:hasPart <info:hdl/1234.5/67890>.

    <info:hdl/1234.5/67890>
        dcterms:isPartOf <some/identifier>.

And so I’ve made a statement about the Item being part of a Resource that is of type “frbr:Work”, A thing that has no explicit “DSpaceObject” type constraint to it.

If "non-DSpaceObjects" can be expressed so easily, what are “DSpaceObjects”? Originally, I started to think that there really isn’t that much to a DSpaceObject. That is is just an identifier to which we can assert statements about by using it as a “subject”. But this role isn’t trivial, being an identifier actually means that we have very important concerns about its existence and long term referential integrity, and most importantly what is the authority that defines and maintains it. Being a DSpaceObject means that in the DSpace Model, DSpace Policies can be asserted and attached to the Resource. In this light, there is something missing about the "Context" that the above set of statements were asserted within.

Context, Named Graphs and Quad-stores:

A DSpaceObject represents something that may have Policies attached to it. Generally, these Policies represent relationships that identify who has rights to create, retrieve update and delete its parts. Many triple-store implementations have been extended to support an additional relationship attached to the Triple called a "Context" or a "Graph"

Mulgara is a quadstore that is used by Fedora ATM, likewise Sesame is also a quadstore. Sesame supports quads with what is called a "Context", in Mulgara, they refer to it as a Named Graph or Model. Here is an example of doing inserts into Mulgara such that they are associated with a Name/Context...

insert <user:brian> <foo:hasValue> '1'
into <rmi://localhost/server1#devx>;

insert <user:brian> <foo:hasFavoriteColor> 'blue'
into <rmi://localhost/server1#devx>;

insert <user:david> <foo:hasValue> '7'
into <rmi://localhost/server1#devx>;

Here the identifier for the graph being inserted into is <rmi://localhost/server1#devx>. Using Quads to represent actual DSpaceObjects Gives us an opportunity to assert container-like control over the statements we make about a DSpaceObject, even if the subject of the statement is something else... For instance, we can say:

#this is a Named Graph represented in {} (I made up the predicate).
<info:hdl/1234.5/67890> dspace:defines
{

    <info:hdl/1234.5/67890>
    dc:title “My Item”;
    dspace:hasBitstream <info:hdl/1234.5/67890/1>;
    dspace:hasBitstream <info:hdl/1234.5/67890/2>;
        dcterms:isPartOf <some/identifier>.

    <info:hdl/1234.5/67890/1>
    dspace:isPartOfItem <info:hdl/1234.5/67890>;
    dspace:name “file_1.ext”.

    <info:hdl/1234.5/67890/2>
    dspace:isPartOfItem <info:hdl/1234.5/67890>;
    dspace:name “file_2.ext”.

    <some/identifier>
    a frbr:Work;
    dcterms:hasPart <info:hdl/1234.5/67890>.
}

Now we know the context whereby this metadata was is defined for the DSpace Item, we can start to talk about other Contexts which may define the permissions and policies that apply to this metadata.

<info:hdl/1234.5/88888> dspace:defines
{

    <info:hdl/1234.5/67890>
        a dspace:ResourcePolicy
        dspace:hasGroup <info:hdl/1234.5/88888>; # some group
        dspace:hasAction "READ"
        dspace:hasResource <info:hdl/1234.5/67890>
}

The above graph asserts that The Item above should be readable to group 1234.5/88888.

From this we can begin to see that RDF can be used to decompose and express the objects and their relationships in a DSpace instance. My hope is that this shows us some building blocks upon which we can begin to construct an API for DSpace 2.0 which would allow the level of "Resource Definition" we find available when expressing resources generically in RDF. My initial opinion is that this may only need to be based on the following few types:

DSpaceResource: A DSpaceObject that is also a Named Graph

ResourcePolicy: A DSpaceObject that Asserts Policies the system will evaluate.Resource

Group: A Group of individual epersons that may be assigned to a Policy

EPerson: A FoaF Person who may have rights int he system based on the Groups/Policies they are assigned to.

After implementing the above as concrete classes, all other more Specific Types become RDF resources expressed with some specific ontological constraints that the ontology author gets to define and for which the system is "agnostic" to the occurrence of.

Expressing More Fedora Relationships Using RDF.

2008-09-28T00:57:00.001-07:00

I think that Ben O'Stein makes an excellent point about the use of RDF to express the relations between individual Datastreams in his post "Internal object relationships - in the context of Fedora and Solr indexing.". His usage of dcterms:hasFormat seems certainly appropriate in this case. I might take this a step further and suggest that much of the System level and descriptive "DC" metadata can be appropriately mapped into the RDF space for Fedora.

While ORE might be one possibility for expressing a complex digital object, I caution that the perception around ORE is that one actually "needs it" to express relationships between resources when that is actually the very nature of RDF. The ability to assert relationships is a product of triple statements whose subject and object may contain references to resources and is wholly adequate enough to express the relationships in the manner that Ben has pointed out. I suggest this usage is actually more semantically meaningful than that of the generic concept of an Aggregation expressed in ORE. In fact, I find that the specified use in RDF described by the ORE group is a two edged sword with the following difficult tradeoffs:

Using it instead of a more common relation can actually result in the loss of semantic richness in a graph of resources because it forces the relationships to be represented using ORE predicates rather than those more common and which carry richer meaning, this is very unlike dcterms:relation style predicates that are "free radicals" of semantic meaning that can be peppered throughout ones preexisting ontology.

If one wishes to retain that semantic richness, one has to duplicate the relations one already has alongside those of ORE, resulting in bloating of statements describing the same relationship with different predicates.

The only mechanism I can see to alleviate this with the ORE specification would be to actually extend/refine the ORE ontology in ones own RDFS/OWL ontology domain model, in the same way as ORE has done with Dublin Core. See thread...

http://groups.google.com/group/oai-ore/browse_thread/thread/e77d3ab643077dd3

Its only then that one can actually state in more explicit detail, the nature of the relationships in an aggregation. (I/E/ partOfCollection, hasFormat, isFormatOf without duplication. Cheers to Ben for the excellent reuse of an existing common ontology rather than inventing a new one.

Collaborations between Fedora and DSpace... Happy Software Freedom Day!

2008-09-21T12:59:00.001-07:00

Happy Belated Software Freedom Day! http://www.softwarefreedomday.org/

I'm excited to recently be participating in efforts within our community to find new synergies between DSpace and Fedora. Likewise, the recent announcement by both Foundations that they are excited about working together is positive.

I originally met in the spring with Chris Wilper, Dan Davis and Matthew Zumwalt of the Fedora Commons community at JA-SIG 2008 in St. Paul and had several very positive interactions with them about synergies between the two projects. I recall that during that discussion, the strongest point made was that DSpace and Fedora fill very different niches in the ecosystem of Digital Libraries and Content Management. I was excited to see the recognition of this on their side of the table as well.

At that time we were just warming up for the DSpace GSoC 2008 selection process and had several interesting options come onto the table around this topic of interoperability between DSpace and Fedora. I recall at the time, it the original statement that it should be in the list came for either Jim Downing or Scott Yeadon back in the early spring of this year. My point being, that the roots of the latest endeavors are arising from multiple sources within our communities. But this said, I feel the recent announcements by both foundations to begin working collaboratively are now galvanizing this process. I look forward to participating in these new initiatives and hope others are interested as well.

I think we are already starting to see the manifestation of this relationship today. There have been several projects within the DSpace community that have been going on this summer and I'd like to informally report on them.

Google Summer of Code:

Recently DSpace participated in the Google Summer of Code, we had four students working on various projects (http://wiki.dspace.org/ index.php/Google_Summer_of_Code). All these projects were very interesting and successfully completed by the students. The DSpace/Fedora integration project (Andrius Blažinskas mentored by Richard Rodgers) and Semantic Web Enabling project (Peter Coetzee mentored by myself) both explored extremely positive possibilities around opening up the backend assetstore and metadata management services of DSpace to alternative solutions and allowing for the mapping and storage of DSpace Content and Metadata to Fedora Digital Objects and alternatively, its expression in RDF and exposure as Linked Open Data via SPARQL endpoints.

DSpace Fedora Integration:

Mapping DSpace Objects to Fedora Digital Object representations.
http://wiki.dspace.org/index.php/Google_Summer_of_Code_2008_Fedora_Integration

At its heart the Fedora integration is an implementation of the current Data Access Object interfaces we have been working on for DSpace 2.0 and successfully represented DSpace Communities, Collections, Items and their Bitstream Contents as Fedora Objects with RELS-EXT relations between them and metadata expressed as XML datastreams.

DSpace RDF Triplestore Integration:

http://wiki.dspace.org/index.php/Google_Summer_of_Code_2008_Fedora_Integration

The recent activity around the Linked Open Data community and the Semantic Web led us to want to explore how the DSpace data model and metadata services could be implemented on top of an RDF triplestore and how those LoD Representations could be exposed to the world and made queriable via SPARQL endpoints. The outcome of the project allowed us to

1.) Produce an ontology for DSpace (http://purl.org/dspace/model) for serialization into RDF triple-stores and for querying via SW/LoD SPARQL endpoints.

2.) Implement a Storage layer for DSpace 2.0 that provided a mapping to RDF and Query Support capabilities via D2RQ mappings and Jena Triplestores.

DSpace 2.0 Funded Development:

This Fall I am a member of a funded team working to establish the foundations for a concrete DSpace 2.0 design and implementation. This includes, among various other topics, re-architecting the DSpace Data Model and aligning it with other platforms/standards for representing content in repositories. In my opinion, this represents an ideal opportunity to open discussions within both communities on how these tools can be better leveraged, their niches better defined, and best practices on their interoperability better established.

Our initial activity around DSpace 2.0 has involved opening up the data model to support the better attachment of metadata to DSpace objects (Communities, Collections, Items, Bundles, Bitstreams) and also to support the attachment of "Content" more generically along the various objects within the model. For us this presents a new need for Common shared API/protocols/services that will allow for the configuration of extensible and stackable Content and Metadata Repository Interfaces in DSpace 2.0 and a more common shared representation of that Content+Metadata across such a heterogeneous environment of services. In researching this possibility for an implementation, I've reviewed the Fedora APIs and Object model, as well as those API found in Sword, JCR(170/283) and CMIS.

What intrigues me the most about these projects above, is that the problem domain for enabling the exposure and management of content in tools such as DSpace and Fedora is actually a subset of a larger direction that the whole CMS industry/Sector is moving in with technologies and standards such as APP and CMIS. This is very promising for the future of our services as we will begin to see these initiatives begin to solve some of the problems we experience right now to heterogeneous parallel solutions to the same problem domain.

External Technology Fronts:

In my opinion, (1) the Linked Open Data, semantic web, RDF centric approach to describing the relationships between "Resources" and (2) exposing these Resource representations as the basis for a RESTful metadata service (with endpoints such as SQL2,JQOM ,SPARQL for query) will form the basis for the future interoperability of not only Fedora/DSpace tools, but also for these tools with two larger communities:

A,) The Linked Open Data movement: Semantically link Data Web, Projects such as LoD, DCMI and Library of Congress exposure of metadata and classification registries.

B.) The CMIS/JCR content repository standards communities that are manifesting common shared API and protocols for interacting more generically with Content Repositories.

I'd be quite interested in seeing how these technologies will alter the Library community’s concepts and expectations behind registries and vocabulary. It can already be seen today in projects like the Library of Congress Standards & Research Data Values Registry

http://www.loc.gov:8081/standards/registry/lists.html
http://metadataregistry.org/
http://dcmi.kc.tsukuba.ac.jp/dcregistry/

I hope to see it begin to impact other registries as we begin to recognize (1) our metadata is content and (2) it is heavily interlinked. I hope to see the effects eventually percolate into projects such as the GDFR/Pronom Format Registry services.

http://www.nationalarchives.gov.uk/PRONOM
http://www.formatregistry.org/

I would be very excited to see common response formats (SPARQL/XML, RDF/XML, JSON) and common Query Syntaxes (SPARQL) on such data-sets in such a way as to allow the reuse of existing clients and popular technologies that can be more easily transferred to employees and
across positions within the sector.

Application to our Community:

Interestingly, because of evolving in a grant funded research community, many of these projects perceive their work as competitive or opposing in nature. I perceive a revolution occurring, at least within our own small community of DSpace, where work is shifting away from this strategy and towards a more traditional Open Source / Open Community model which, while appearing altruistic at first, is actually self serving for those individuals and organizations that participate within it, allowing them to reduce and/or altogether eliminate this replication of effort and allow healthier synergies to evolve.

It is becoming clearer that many of these projects have important and separate niches to fill within the larger sector. For instance, in the larger sector, JCR and CMIS are not competitive but complimentary.

JCR = a API
CMIS = a Protocol

A JCR CMIS driver represents a opportunity to see how these are complementary and how they would serve both the JAVA community and the larger CMS community, Likewise, they provide a clear blueprint for API implementation in other languages as well as for vendors that wish to implementing such services.

Applying the same blueprint in the Fedora/DSpace communities we see an opportunity for DSpace and Fedora Communities to clarify the roles of API and Protocols within them

Applications:
DSpace = a User Application (currently with its own internal CMS)
Fedora = a User Application that is a CMS

Protocols:
Fedora API (SOAP/REST) = a SOAP/REST protocol for interacting with Fedora
DSpace LNI = a SOAP/WEB-DAV protocol for interacting with DSpace
Sword = a APP/REST protocol for interacting with DSpace, Fedora, etc

The latter group represents a set of services with protocols that allow one to interact with a very "narrow niche" of CMS applications in the Open Repositories Community. I find this the interesting point where ventures with more commercial CMS protocols such as CMIS may become the future direction of, should we be considering that CMIS is a super-set of what Sword is going to give us?

I feel there are abstractions that will become more salient as we explore the collaborative space between DSpace and Fedora.

A.) Identification:

I was recently intrigued to find out that Fedora can support the identification of its ID's using URI other than the "info:fedora" scheme:namespace.

http://www.fedora.info/definitions/identifiers/
http://oxfordrepo.blogspot.com/2008/01/conclusions-on-uuids-and-local-ids-in.html

I think we are starting to recognize that identification of resources within a CMS needs to be pluralistic in nature. that there are so many efforts to establish naming/identification efforts within the community

B.) Relationships (Ontology)

I'm intrigued think that this capability, and the usage of the RELS-EXT RDF datastream as a holding place for dspace relationships/ metadata found in the dspace 2.0 Ontology allows a clean alignment between DSpace Resources (Objects) and Fedora Objects and will hold interesting possibilities for bringing together DSpace services on top of Fedora Repositories.

DSpace and Fedora RELS-EXT Ontologies offer an opportunity for making such above relationships more explicit. Currently, the RELS-EXT ontology is a closed ontology that does not extend upon known common Properties that already exist in the RDF community today, I can see a serious benefit in making the Properties int he RELS-EXT ontology be made subProperties of dcterms:isPartOf / dcterms:hasPart. This sort of alignment would start these ontologies down the road to alignment as the DSpace Ontology already uses them. Likewise, if there is any benefit to using other shared ontologies (OAI-ORE for instance, as the basis for expressing relations that represent aggregations/ containership. I see many further opportunities to begin to draw equivalencies in this area.

Alignments in ontology between DSpace and Fedora will allow us to begin to utilize inference capabilities in RDF triplestores such as Mulgara to be able to retrieve equivalent statements made in the two ontologies in a common ontological expression (DC, DCTERMS, ORE, BIBO, etc) rather than two separate application specific ontologies.

Conclusion:

In closing, I'll just reiterate that we have great opportunities now for synergy where before there were barriers. I hope that we will see this reflected in the conferences that we attend, attending the JA-SIG conference last Spring opened my eyes to how the community can benefit when developers from different projects are all placed in a room together to talk about the technologies they use. I think this would make for an excellent format for Open Repositories conferences and would benefit our newly formed foundations and communities immensely. Last year we saw Bar-Camps becoming popular and happening at Open Repositories, it would be very exciting to see more opportunities for "Un-Conferences" where we can bring together development teams from both communities in a more formal setting to promote collaboration.

Cheers,
Mark Diggory