...
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:
- We want to extend the functionality provided by the demo image collection by allowing these collections to be modified using the atom publishing protocol.
- Existing demo SDefs and SDeps from the image collection remain unchanged
- Images added/modified via AtomPub are considered FULL_SIZE
- There exists a ServiceDocument that enumerates all the image collections in the repository and their collection feed URIs (as provided by the APP)
- Each image collection has a collection feed URI
- In accordance with the APP images may be added, removed, or replaced through through this feed
- Adding an object to the feed implies adding a new object to the repository - but the client shall have no awareness of this process
- 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:
{{[http:// Wiki Markup http://(fedora.server)/services/(object-pid)/(sdef-pid)/(method)
]\[/additional
\]
}}
...where \where [/additional\] could be parameters, or additional path elements in the URI. Wiki Markup
For example, one of our service methods above would look like http://example.org/fedora/services/demo:SmileyStuff/atom:Collection/entries
...
These objects would then define the following URIs and interaction model:
*http://example.org/fedora/services/thought-exp:ImageCollection/atom:Domain/feeds*
GET - Service Document containing all image collection feeds.
*
Code Block | ||||
---|---|---|---|---|
| ||||
<service xmlns="http:// |
...
www.w3.org/ |
...
GET - Service Document containing all object datastream feeds. This could possibly be a very large list, resulting in a ginormous Service Document Unlike atom feeds, I don't believe one can implement pagination for this document.
...
2007/app" xmlns:atom="http:// |
...
www.w3.org/ |
...
2005/Atom"> <workspace> <atom:title>Image Collections</atom:title> <collection href="http://example.org/fedora/services/demo:SmileyStuff/thought-exp:ImageCollection/ |
...
GET - Service document for one image collection. Service documents may enumerate the acceptable content types, so an image collection may list off supported image formats (such as image/png, image/jpeg, etc
...
feed"> <atom:title>Smiley Stuff Images</atom:title> <accept>image/jpeg</accept> </collection> <collection href="http://example.org/fedora/services/demo:FrownyStuff/thought-exp:ImageCollection/feed |
...
" >
<atom:title>Frowny stuff</atom:title>
<accept>image/png</accept>
<accept>image/jpeg</accept>
<accept>image/gif</accept>
</collection>
</workspace>
</service>
|
http://example.org/fedora/services/thought-exp:Datastream/atom:Domain/feeds
GET - Service Document containing all object datastream feeds. This could possibly be a very large list, resulting in a ginormous Service Document Unlike atom feeds, I don't believe one can implement pagination for this document.
...
GET - Get an atom feed of all images in a collection represented by the PID object.
POST - Accept only media items (i.e. images in supported formats). A POSTed image would cause the following to happen:
- Create Fedora object for new item created
- If the 'Slug' header is defined, possibly assign object a NEW_PID derived from that
- Return an ATOM entry found at: http://example.org/fedora/services/(NEW_PID)/thought-exp:ImageItem/entry
*http://example.org/fedora/services/(PID)/thought-exp:ImageItemImageCollection/media*service
GET - Get an image
PUT - Replace an image. The item's 'entry' link will reflect the update
*http://example.org/fedora/services/(PID)/thought-exp:ImageItem/entry*
GET - Get the entry
PUT - Replace entry metadata
*http://example.org/fedora/services/(PID)/thought-exp:Datastreams/service*
GET - Service document for one object. Service documents may enumerate the acceptable content types.. perhaps it makes sense to introspect in the object's models, but it may be more flexible not to enumerate anything at all, if that's possible.
Service document for one image collection. Service documents may enumerate the acceptable content types, so an image collection may list off supported image formats (such as image/png, image/jpeg, etc
Code Block | ||||
---|---|---|---|---|
| ||||
<service xmlns="http://www.w3.org/2007/app" xmlns:atom="http://www.w3.org/2005/Atom">
<workspace>
<atom:title>Image Collections</atom:title>
<collection href="http://example.org/fedora/services/demo:SmileyStuff/thought-exp:ImageCollection/feed">
<atom:title>Smiley Stuff Images</atom:title>
<accept>image/jpeg</accept>
</collection>
</workspace>
</service>
|
http://example.org/fedora/*http://example.org/fedora/services/(PID)/thought-exp:DatastreamsImageCollection/feed*
GET - Get an atom feed of all datastreams and versions images in a collection represented by the PID object.
POST - Accept datastream content. POSTed data would cause the following to happen:
...
- If the 'Slug' header is defined, assign object a datastream ID based on (identical to?) that.
Code Block | ||||
---|---|---|---|---|
| ||||
<feed xmlns="http://www.w3.org/2005/Atom">
<title>Smiley Stuff Images</title>
<link href=" |
...
http://example.org/fedora/services/ |
...
demo:SmileyStuff/thought-exp: |
...
ImageCollection/feed" rel="self"/>
<updated>1980-03-20T09:15:02Z</updated>
<author>
<name>Chis Wilper</name>
</author>
<id>info:fedora/demo:SmileyStuff/thought-exp:ImageCollection</id>
<entry>
<title>Smiley Toilet Brush</title>
<id>info:fedora/demo:SmileyToiletBrush/thought-exp:ImageItem</id>
<updated>1979-10-07T17:17:08Z</updated>
<content type="image/png"
src="http://example.org/fedora/services/demo:SmileyToiletBrush/thought-exp:ImageItem/media"/>
<link rel="edit-media"
href="http://example.org/fedora/services/demo:SmileyToiletBrush/thought-exp:ImageItem/media" />
<link rel="edit"
href="http://example.org/fedora/services/demo:SmileyToiletBrush/thought-exp:ImageItem/entry" />
</entry>
</feed>
|
POST - Accept only media items (i.e. images in supported formats). A POSTed image would cause the following to happen:
- Create Fedora object for new item created
- If the 'Slug' header is defined, possibly assign object a NEW_PID derived from that
- Return an ATOM entry found at: http://example.org/fedora/services/(NEW_PID)/thought-exp:ImageItem/entry
http://example.org/fedora/services/(PID)/thought-exp:ImageItem/media
GET - Get an image
PUT - Replace an image. The item's 'entry' link will reflect the update
http://example.org/fedora/services/(PID)/thought-exp:ImageItem/entry
GET - Get the entry
Code Block | ||||
---|---|---|---|---|
| ||||
<entry xmlns="http://www.w3.org/2005/Atom">
<title>Smiley Beer Glass</title>
<id>info:fedora/demo:SmileyBeerGlass/thought-exp:ImageItem</id>
<updated>1979-10-07T17:17:08Z</updated>
<content type="image/png"
src="http://example.org/fedora/services/demo:SmileyBeerGlass/thought-exp:ImageItem/media"/>
<link rel="edit-media"
href="http://example.org/fedora/services/demo:SmileyBeerGlass/thought-exp:ImageItem/media" />
<link rel="edit"
href="http://example.org/fedora/services/demo:SmileyBeerGlass/thought-exp:ImageItem/entry" />
</entry>
|
PUT - Replace entry metadata
http://example.org/fedora/services/(PID)/thought-exp:Datastreams/service
GET - Service document for one object. Service documents may enumerate the acceptable content types.. perhaps it makes sense to introspect in the object's models, but it may be more flexible not to enumerate anything at all, if that's possible.
http://example.org/fedora/services/(PID)/thought-exp:Datastreams/feed
GET - Get an atom feed of all datastreams and versions represented by the PID object.
GET - Get an atom feed of all images in a collection represented by the PID object.
Code Block | ||||
---|---|---|---|---|
| ||||
<feed xmlns="http://www.w3.org/2005/Atom">
<title>demo:SmileyBeerGlass datastreams</title>
<link href="http://example.org/fedora/services/demo:SmileyBeerGlass/thought-exp:Datastreams/feed" rel="self"/>
<updated>1980-03-20T09:15:02Z</updated>
<author>
<name>Chis Wilper</name>
</author>
<id>info:fedora/demo:SmileyBeerGlass/thought-exp:Datastreams</id>
<entry>
<title type="text">RELS-EXT</title>
<id>info:fedora/demo:SmileyBeerGlass/thought-exp:Datastream/RELS-EXT</id>
<updated>1979-10-07T17:17:08Z</updated>
<content type="application/rdf+xml"
src="http://example.org/fedora/services/demo:SmileyBeerGlass/thought-exp:Datastream/media?id=RELS-EXT"/>
<link rel="edit-media"
href="http://example.org/fedora/services/demo:SmileyBeerGlass/thought-exp:Datastream/media?id=RELS-EXT" />
<link rel="edit"
href="http://example.org/fedora/services/demo:SmileyBeerGlass/thought-exp:Datastream/entry?id=RELS-EXT" />
</entry>
<entry xmlns:thr="http://purl.org/syndication/thread/1.0">
<title type="text">RELS-EXT.0</title>
<id>info:fedora/demo:SmileyBeerGlass/thought-exp:Datastream/RELS-EXT.0</id>
<updated>1979-10-07T17:17:08Z</updated>
<thr:in-reply-to ref="info:fedora/demo:SmileyBeerGlass/thought-exp:Datastream/RELS-EXT"/>
<content type="application/rdf+xml"
src="http://example.org/fedora/services/demo:SmileyBeerGlass/thought-exp:Datastream/media?id=RELS-EXT&version=1979-10-07T17:17:08Z"/>
<link rel="edit"
href="http://example.org/fedora/services/demo:SmileyBeerGlass/thought-exp:Datastream/entry?id=RELS-EXT&version=1979-10-07T17:17:08Z" />
</entry>
</feed>
|
POST - Accept datastream content. POSTed data would cause the following to happen:
- Create a new datastream
- If the 'Slug' header is defined, assign object a datastream ID based on (identical to?) that.
- Return an ATOM entry found at: http://example.org/fedora/services/(PID)/thought-exp:Datastream/entry?id=DSID?version=XYZ, where 'DSID' is the datastream ID and 'version' is the datastream's version. entry shall have edit-media link pointing to unversioned datastream media URI.
http://example.org/fedora/services/(PID)/thought-exp:Datastream/media?id=DSID(&version=2008...)
GET - Get the datastream content
PUT - Put new datastream content (return an error if version is specifed??)
http://example.org/fedora/services/(PID)/thought-exp:Datastream/entry?id=DSID(&version=2008...)
GET - Get entry medatata
PUT - Modify entry metadata (Not sure what consequences are...)
The Other objects...
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 take a look at all CMA and instance objects together, and see if we can map our desired functionality on to them.
Image item model:
Code Block |
---|
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)
Code Block |
---|
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:
Code Block |
---|
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:
Code Block |
---|
pid: thought-exp:ImageItemInstanceImpl
relationship.isDeploymentOf: thought-exp:ImageItem
relationship.isContractorOf: demo:DualResImage
relationship.hasModel: fedora-system:ServiceDeployment-3.0
|
Image collection model:
Code Block |
---|
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:
Code Block |
---|
pid: [collection PID]
relationship.hasModel demo:DualResImageCollection
datastream: QUERY
datastream: XSLT
datastream: LIST
datastream: thought-exp.ImageCollection.ATOM_SERVICE
|
atom image collection SDef:
Code Block |
---|
atom image collection SDep:
Code Block |
---|
...
Wiki Markup |
---|
\*http://example.org/fedora/services/(PID)/thought-exp:Datastream/media?id=DSID\[&version=2008...\]\* |
GET - Get the datastream content
PUT - Put new datastream content (return an error if version is specifed??)
Wiki Markup |
---|
\*http://example.org/fedora/services/(PID)/thought-exp:Datastream/entry?id=DSID\[&version=2008...\]\* |
GET - Get entry medatata
...
page is unfinished. Need to put in discussion and examples, questions/implications, and basic conclusion as to whether this makes sense, and if it truly adds any value to, say, an external APP service.