Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

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:

Wiki Markup{{[http://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

...

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
xml
xml

<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:

  1. Create Fedora object for new item created
    1. If the 'Slug' header is defined, possibly assign object a NEW_PID derived from that
  2. 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
xml
xml

<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:

...

  1. If the 'Slug' header is defined, assign object a datastream ID based on (identical to?) that.

Code Block
xml
xml

<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:

  1. Create Fedora object for new item created
    1. If the 'Slug' header is defined, possibly assign object a NEW_PID derived from that
  2. 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
xml
xml

<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
xml
xml

<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:

  1. Create a new datastream
    1. If the 'Slug' header is defined, assign object a datastream ID based on (identical to?) that.
  2. 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.