Page History

...

For feed 2, we want to allow for the repository to contain multiple image collections, much in the same spirit as extending the functionality of the demo image collection.  Each image collection is represented by its own object in the repository, as are individual image items.  Collection membership is determined by the presence of an 'isMemberOf' relationship from an image to a collection.  Specifically, let's suppose that we wanted the following characteristics:

1. We want to extend the functionality provided by the demo image collection by allowing these collections to be modified using the atom publishing protocol.
   1. Existing demo SDefs and SDeps from the image collection remain unchanged
   2. Images added/modified via AtomPub are considered FULL_SIZE
2. There exists a ServiceDocument that enumerates all the image collections in the repository and their collection feed URIs (as provided by the APP)
3. Each image collection has a collection feed URI
4. In accordance with the APP images may be added, removed, or replaced through through this feed
   1. Adding an object to the feed implies adding a new object to the repository - but the client shall have no awareness of this process
   2. Deleting an object from the feed implies purging the image object from the repository - but the client shall have no awareness of this process

...

Additionally, let's assume that Fedora's REST API exposed URIs for the methods expressed in these SDefs as follows:unmigrated-wiki-markup

{{[http://(fedora.server)/services/(object-pid)/(sdef-pid)/(method)]\[/additional\]}}

Wiki Markup...where  \where  [/additional\] could be parameters, or additional path elements in the URI.

For example, one of our service methods above would look like http://example.org/fedora/services/demo:SmileyStuff/atom:Collection/entries

...

So far, we've really only discussed the public "interfaces" of AtomPub in a writable CMA - the SDefs, URIs, and data formats.  Let us now see if the surrounding objects (take a look at all CMA and instance objects together, content models, and Service Deployments) are tractable... and see if we can map our desired functionality on to them.

Image item model:

pid:                       demo:DualResImage
relationship.hasService:   thought-exp:ImageItem # New Atom functionality
relationship.hasService:   demo:DualResolution   # Original image collection functionality
relationship.hasModel:     fedora-system:ContentModel-3.0
DS-COMPOSITE-MODEL:        datastream: FULL_SIZE # from original demo:DualResImage
                           datastream: MEDIUM_SIZE # from original demo:DualResImage
                           datastream: RELS-EXT:  # from original demo:DualResImage
                           datastream: DC # from original demo:DualResImage

Image item instance (one per image)

pid:                      [item PID]
datastream:               MEDIUM_SIZE
datastream:               FULL_SIZE
datastream:               DC
relationship.isMemberOf   [collection PID] # de facto, see image collection demo objects
relationship.hasModel:    demo:DualResImage

Image item SDef:

pid:                    thought-exp:ImageItem
method:                 service # APP Service document for one image collection
method:                 feed    # atom Image Collection feed
relationship.hasModel   atom:DomainModel # to have atom:Domain/feeds
relationship.hasModel   fedora-system:ServiceDefinition-3.0

Image item SDep:

pid:      thought-exp:ImageItemInstanceImpl
relationship.isDeploymentOf: thought-exp:ImageItem
relationship.isContractorOf: demo:DualResImage
relationship.hasModel: fedora-system:ServiceDeployment-3.0

Image collection model:

pid:                       demo:DualResImageCollection
relationship.hasService:   thought-exp:ImageCollection   # Adds atom collection functionality
relationship.hasModel:     fedora-system:ContentModel-3.0
DS-COMPOSITE-MODEL:        datastream: thought-exp.imageCollection.ATOM_SERVICE
                           datastream: QUERY # from original demo:DualResImageCollection
                           datastream: XSLT  # from original demo:DualResImageCollection
                           datastream: LIST  # from original demo:DualResImageCollection

Image collection instance:

pid:  [collection PID]
relationship.hasModel      demo:DualResImageCollection
datastream:                QUERY
datastream:                XSLT
datastream:                LIST
datastream:                thought-exp.ImageCollection.ATOM_SERVICE

atom image collection SDef:

atom image collection SDep:

page is unfinished.  Need to put in discussion, questions/implications, and basic conclusion as to whether this makes sense, and if it truly adds any value to, say, an external APP service.