Simple Containers and Views

In this example we have a simple OSLC container. We do a GET on it, and request non-member properties (properties about the container itself not the set of members in it). This query parameter is suggested by the Linked Data Profile.

GET http://example.org/projects/project1?non-member-properties

@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix oslc_viewpoint:     <http://open-services.net/ns/core/viewpoint#>.

<http://example.org/projects/project1>
    dcterms:title "My Project";
    oslc_viewpoint:viewpoint
        <http://example.org/projects/project1/vp1>,
        <http://example.org/projects/project1/vp2>.

<http://example.org/projects/project1/vp1>
    a oslc_viewpoint:Viewpoint;
    dcterms:title "Use Case View";
    dcterms:description "View of UML Use Cases and Package Hierarchy".
    
<http://example.org/projects/project1/vp2>
    a oslc_viewpoint:Viewpoint;
    dcterms:title "Sequence Diagrams";
    dcterms:description "View of all UML Sequence Diagrams".

The viewpoints are also containers, and GETing them will return pages of members of that viewpoint (ordered).

@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix rdfs:    <http://www.w3.org/2000/01/rdf-schema#>.
@prefix ldp:     <http://www.w3.org/ns/ldp#>.
@prefix oslc:    <http://open-services.net/ns/core#>.
@prefix oslc_viewpoint:     <http://open-services.net/ns/core/viewpoint#>.

<http://example.org/projects/project1/vp1> 
    a oslc_viewpoint:Viewpoint ;
    dcterms:title "Use Case View" ;
    dcterms:description "View of UML Use Cases and Package Hierarchy".

<http://example.org/projects/project1/vp1?page=1>
    a ldp:Page;
    ldp:pageOf <http://example.org/projects/project1/vp1>;
    ldp:nextPage <http://example.org/projects/project1/vp1?page=2>;
    rdfs:member 
          <http://example.com/projects/projects1/res1?viewpoint=vp1>,  
          <http://example.com/projects/projects1/res2?viewpoint=vp1>,  
          <http://example.com/projects/projects1/res3?viewpoint=vp1>,  
          <http://example.com/projects/projects1/res4?viewpoint=vp1>,  
          <http://example.com/projects/projects1/res5?viewpoint=vp1>.  


<http://example.com/projects/projects1/res1?viewpoint=vp1>
    a oslc_viewpoint:ViewItem ;
    oslc_viewpoint:resource <http://example.com/projects/projects1/res1> ;
    rdfs:label "Resource 1";
    oslc:icon <http://example.com/icons/uml/diagram>.

<http://example.com/projects/projects1/res2?viewpoint=vp1>
    a oslc_viewpoint:ViewItem ;
    rdfs:label "Resource 2";
    oslc_viewpoint:prev <http://example.com/projects/projects1/res1>; 
    oslc_viewpoint:children <http://example.com/projects/projects1/res2?childrenInViewpoint=vp1>;
    oslc:icon <http://example.com/icons/uml/package> .

<http://example.com/projects/projects1/res3?viewpoint=vp1>
    a oslc_viewpoint:ViewItem ;
    rdfs:label "Resource 3";
    oslc_viewpoint:prev <http://example.com/projects/projects1/res2>;
    oslc:icon <http://example.com/icons/uml/package> .

<http://example.com/projects/projects1/res4?viewpoint=vp1>
    a oslc_viewpoint:ViewItem ;
    rdfs:label "Resource 4";
    oslc_viewpoint:prev <http://example.com/projects/projects1/res3>; 
    oslc_viewpoint:children <http://example.com/projects/projects1/res4?childrenInViewpoint=vp1>;
    oslc:icon <http://example.com/icons/uml/package> .

<http://example.com/projects/projects1/res5?viewpoint=vp1>
    a oslc_viewpoint:ViewItem ;
    rdfs:label "Resource 5";
    oslc_viewpoint:prev <http://example.com/projects/projects1/res4>;
    oslc:icon <http://example.com/icons/uml/package> .

There are some problems with this when compared to the LDP. In the LDP, our project is like a LDP Container. LDP Containers can be ordered, which is one of the things a viewpoint does for a container. In the LDP however ordering is rather specific (Section 5.1.3).

LDPC servers MAY represent the members of a paged LDPC in a sequential order. If the server does so, it MUST be specify the order using a triple whose subject is the page URI, whose predicate is ldp:containerSortCriteria, and whose object is a rdf:List of ldp:containerSortCriterion resources. The resulting order MUST be as defined by SPARQL SELECT’s ORDER BY clause [SPARQL-QUERY].

In our case it is possible that resources in a given container don’t have a single property that can be used in an ORDER BY clause. Instead we’d like to keep such details away from the client, allowing the server and the rules behind the viewpoint to define what the ordering is.