Difference between revisions of "ISSUE-37"

From Linked Data Platform
Jump to: navigation, search
(Created page with "{| class="wikitable" |service basics| any atompub server exposes a "service document" (http://tools.ietf.org/html/rfc5023#section-8) that describes what the server is exposing. e…")
 
Line 1: Line 1:
 
{| class="wikitable"
 
{| class="wikitable"
|service basics|
+
|Model Aspect
any atompub server exposes a "service document"
+
|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
 
(http://tools.ietf.org/html/rfc5023#section-8) that describes what the
 
server is exposing. each service document lists a set of "workspaces"
 
server is exposing. each service document lists a set of "workspaces"
Line 12: Line 15:
 
workspace.
 
workspace.
 
|-
 
|-
|collection basics|
+
|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
 
list of members (http://tools.ietf.org/html/rfc5023#section-10), and very
 
list of members (http://tools.ietf.org/html/rfc5023#section-10), and very
Line 24: Line 27:
 
(http://tools.ietf.org/html/rfc5023#section-8.3.6) to be classified.
 
(http://tools.ietf.org/html/rfc5023#section-8.3.6) to be classified.
 
|-  
 
|-  
|creating collection members|
+
|creating collection members
any kind of resource can be listed in a
+
|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 45: Line 48:
 
gets some URI under the control of the atompub server.
 
gets some URI under the control of the atompub server.
 
|-
 
|-
|member identity|
+
|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
 
to the atom model, each entry MUST have an <id>
 
to the atom model, each entry MUST have an <id>
Line 62: Line 65:
 
collections.
 
collections.
 
|-
 
|-
|interacting with members|
+
|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
 
mechanisms. if members are editable, an "edit" link in the entry
 
mechanisms. if members are editable, an "edit" link in the entry
Line 76: Line 79:
 
itself.
 
itself.
 
|-
 
|-
|interacting with collections|
+
|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
 
working on a small addition to the spec that addresses that). also,
 
working on a small addition to the spec that addresses that). also,
 
collections have no structure, they have a URI and accept entries. this
 
collections have no structure, they have a URI and accept entries. this
 
means there is no hierarchy to collections, it's a flat space.
 
means there is no hierarchy to collections, it's a flat space.
}
+
|}

Revision as of 18:26, 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.