ISSUE-37
From Linked Data Platform
| Line 1: | Line 1: | ||
{| class="wikitable" | {| class="wikitable" | ||
| - | + | !Model Aspect | |
| - | + | !AtomPub (http://lists.w3.org/Archives/Public/public-ldp-wg/2012Nov/0127.html) | |
|- | |- | ||
| - | + | !service basics | |
|any atompub server exposes a "service document" | |any atompub server exposes a "service document" | ||
(http://tools.ietf.org/html/rfc5023#section-8) that describes what the | (http://tools.ietf.org/html/rfc5023#section-8) that describes what the | ||
| Line 15: | Line 15: | ||
workspace. | workspace. | ||
|- | |- | ||
| - | + | !collection basics | |
|a collection has a URI where you can start | |a collection has a URI where you can start | ||
interacting with the collection, at the most basic level you can GET a | interacting with the collection, at the most basic level you can GET a | ||
| Line 28: | Line 28: | ||
|- | |- | ||
|creating collection members | |creating collection members | ||
| - | + | !any kind of resource can be listed in a | |
collection (http://tools.ietf.org/html/rfc5023#section-4.2), and | collection (http://tools.ietf.org/html/rfc5023#section-4.2), and | ||
everything that is in a collection is represented by an entry. entries | everything that is in a collection is represented by an entry. entries | ||
| Line 48: | Line 48: | ||
gets some URI under the control of the atompub server. | gets some URI under the control of the atompub server. | ||
|- | |- | ||
| - | + | !member identity | |
|a collection is a representation of members, and thus | |a collection is a representation of members, and thus | ||
contains a list of entries representing each individual member. according | contains a list of entries representing each individual member. according | ||
| Line 65: | Line 65: | ||
collections. | collections. | ||
|- | |- | ||
| - | + | !interacting with members | |
|members are listed when GETting a collection, | |members are listed when GETting a collection, | ||
and their identity and metadata about them is exposed through regular atom | and their identity and metadata about them is exposed through regular atom | ||
| Line 79: | Line 79: | ||
itself. | itself. | ||
|- | |- | ||
| - | + | !interacting with collections | |
|like workspaces, collections just exist, | |like workspaces, collections just exist, | ||
and atompub does not define how to create or delete them (i am currently | and atompub does not define how to create or delete them (i am currently | ||
Revision as of 18:33, 7 December 2012
| Model Aspect | AtomPub (http://lists.w3.org/Archives/Public/public-ldp-wg/2012Nov/0127.html) |
|---|---|
| service basics | any atompub server exposes a "service document"
(http://tools.ietf.org/html/rfc5023#section-8) that describes what the server is exposing. each service document lists a set of "workspaces" (http://tools.ietf.org/html/rfc5023#section-8.1), which are just a grouping construct for "collections". workspaces have no interaction semantics in atompub, there is no protocol for creating or deleting them; they just exist. each workspace lists a set of "collections" (http://tools.ietf.org/html/rfc5023#section-10), which is by far the most central construct in atompub. a collection can be listed in more than one workspace. |
| collection basics | a collection has a URI where you can start
interacting with the collection, at the most basic level you can GET a list of members (http://tools.ietf.org/html/rfc5023#section-10), and very likely this is somehow paginated (http://tools.ietf.org/html/rfc5023#section-10.1). through its listing in a service document, the collection exposes some interaction information, such as which kind of mediatypes it will accept (http://tools.ietf.org/html/rfc5023#section-8.3.4), and how members of the collection might use categories (http://tools.ietf.org/html/rfc5023#section-8.3.6) to be classified. |
| creating collection members | any kind of resource can be listed in a
collection (http://tools.ietf.org/html/rfc5023#section-4.2), and everything that is in a collection is represented by an entry. entries follow the standardized metadata model defined by atom (http://tools.ietf.org/html/rfc4287), but atompub distinguishes two kinds of entries. if a client POSTs an "entry resource" (an atom entry following atom's metadata model), the server pretty much takes this entry resource and starts listing it in the collection as a member. if a client has POSTed a "media resource" (pretty much anything that's not an entry by itself, often something like an image media type), which has to be in one of the accepted media types of the collection, the server accepts this media resource and creates a "media link entry", which will then represent this media resource when you list the collection contents. servers might try to be smart about populating metadata fields in the entry and for example look at exif data to populate certain fields. the interesting aspect of this setup is that you POST one thing, and create two resources (http://tools.ietf.org/html/rfc5023#section-9.6), and big media files might for example get added to a CDN and get a CDN URI, whereas the entry gets some URI under the control of the atompub server. |
| member identity | a collection is a representation of members, and thus
contains a list of entries representing each individual member. according to the atom model, each entry MUST have an <id> http://tools.ietf.org/html/rfc4287#section-4.2.6, which is a URI but has no interaction semantics (specifically, best practice suggests that minting URIs that are not actionable might be a good idea http://web.archive.org/web/20110514113830/http://diveintomark.org/archives/ 2004/05/28/howto-atom-id). entries may have embedded content, or may link to the content they are representing (http://tools.ietf.org/html/rfc4287#section-4.1.3). identity is established by the entry <id>, and this is particularly important in scenarios where collections may be aggregated and filtered and repurposed: entry identity must always be visible in the <id>, and thus identity can be tracked across paths where entries may get repurposed in various collections. |
| interacting with members | members are listed when GETting a collection,
and their identity and metadata about them is exposed through regular atom mechanisms. if members are editable, an "edit" link in the entry (http://tools.ietf.org/html/rfc5023#section-11.1) will allow clients to update the member entry, by using this link to PUT or DELETE the entry resource. if the entry is a media link entry, then there might be a "edit-media" link in the entry (http://tools.ietf.org/html/rfc5023#section-11), which will allow clients to update the media resource, by using this link to PUT or DELETE the media resource. this model allows clients to both interact with a media resource's metadata (the "media link entry"), and the media resource itself. |
| interacting with collections | like workspaces, collections just exist,
and atompub does not define how to create or delete them (i am currently working on a small addition to the spec that addresses that). also, collections have no structure, they have a URI and accept entries. this means there is no hierarchy to collections, it's a flat space. |
