ClassContainer

From Linked Data Platform
Jump to: navigation, search

A ClassContainer is a an LDP container that is connected to an RDF Class. The items in the container are members of the class, in general.

ClassContainers are advertised using a triple like:

 my:alaskaPhotos ldp:membersOf my:AlaskaPhoto.

This states that my:alaskaPhotos is an ldp:ClassContainer which provides access to the set of members of the the class my:AlaskaPhoto. This would likely be provided in the intrinsic (empty-container) triples of my:alaskaPhotos and/or in the schema/ontology/namespace document for my:AlaskaPhoto. The triple must be provided in a Link header on the ClassContainer.

1 Discovering Members

Clients can find out which resources are members of the class by doing a GET on its associated class container. The returned contents will include rdf:type triples, like:

<img3721> a my:AlaskaPhoto.
<img2194> a my:AlaskaPhoto.
...

2 Adding and Removing Non-Hosted Members

Clients can update the class container state graph like any other RDF graph resource, using PUT or PATCH or SPARQL operations on an associate endpoint. Doing so has the obvious semantics of making the server (and watching clients) learn or forget the fact that the given resources are members of the given class.

3 POSTing Members

Clients can request the server host a representation of a class member by sending the representation to the server as POST to the ClassContainer. This only makes sense when the member is an information resource.

4 POSTing data about members

Clients can request the server host a representation of data about a class member by sending a representation of that data as a POST to a ClassContainer, and including a Link header stating which items are to be considered class members. For example, given

 </conf/attendees> ldp:membersOf </aboutConf#Attendee>.

one could register a person as an Attendee by (roughly):

POST /conf/attendees
Link: </aboutConf#Attendee> rel=type target=<#>
Content-Type: text/turtle
<#> foaf:name "Joe Attendee".

5 DELETE and garbage collection

A client can request that the server no longer host something created by POST by doing a DELETE. This removes the type triple from the container, unless that type triple has some other provenance.

Removing the type triple from the container SHOULD cause the server to DELETE the resource, unless it's in some other container

6 Filtering and Inclusion

Container filtering and inclusion corresponds to the subclass relationship, so it can be provided simply by stating that relationship. The client will follow the necessary links to determine and maintain this relationship.