Architecture Management wiki

Meeting 21 Nov 2013

JimConallen — Thu, 21 Nov 2013 07:19 EST

Date: 21 November 2013
Time: 7:00 AM Pacific, 10:00 AM Eastern, 3:00 PM UK, 4:00 PM Frankfurt, 5:00 PM Haifa, 8:30 PM Bangalore
Call In Number: (emailed)
Participation request: contact Jim Conallen

Agenda

Update on Core activities
Update from OMG’s OSLC4MBSE workgroup
Continue discussions of structure lists of resources as used in DM viewpoints and DOORS requirements modules

Active topics

Discuss ongoing work at OMG related to OSLC integration
Structured Views
Link Type Predicates
MDD and Transformations

Attendance

Regrets: John Crouchley, Nir Mashkif

Attendees:

Minutes

Meeting 21 Nov 2013

JimConallen — Thu, 21 Nov 2013 07:18 EST

Date: 21 November 2013
Time: 7:00 AM Pacific, 10:00 AM Eastern, 3:00 PM UK, 4:00 PM Frankfurt, 5:00 PM Haifa, 8:30 PM Bangalore
Call In Number: (emailed)
Participation request: contact Jim Conallen

Agenda

Update on Core activities
Update from OMG’s OSLCMBSE workgroup
Continue discussions of structure lists of resources as used in DM viewpoints and DOORS requirements modules

Active topics

Discuss ongoing work at OMG related to OSLC integration
Structured Views
Link Type Predicates
MDD and Transformations

Attendance

Regrets: John Crouchley, Nir Mashkif

Attendees:

Minutes

Meeting 24 Oct 2013

JimConallen — Thu, 24 Oct 2013 09:01 EDT

Date: 24 October 2013
Time: 7:00 AM Pacific, 10:00 AM Eastern, 3:00 PM UK, 4:00 PM Frankfurt, 5:00 PM Haifa, 8:30 PM Bangalore
Call In Number: (emailed)
Participation request: contact Jim Conallen

Agenda

Update from OMG’s OSLCMBSE workgroup
Continue discussions of structure lists of resources as used in DM viewpoints and DOORS requirements modules

Active topics

Discuss ongoing work at OMG related to OSLC integration
Structured Views
Link Type Predicates
MDD and Transformations

Attendance

Regrets: John Crouchley, Nir Mashkif, Steve Speicher

Attendees:

Minutes

Architecture Management Meetings

JimConallen — Thu, 24 Oct 2013 08:59 EDT

Meetings will be held bi-weekly. Please contact Jim Conallen for call in numbers and information.

Agendas and Minutes

	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2013	3, 17, 31	14, 28	~~[14]~~, ~~[28]~~	~~[11]~~, 25	9, 23	6, 20	~~[4]~~, 18	1, ~~[15]~~, 29	12, 26	~~[10]~~, 24	7, 21

	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2012		2, 16	1, 15 29	12, 26	24	7, 21	5, 19	2, 16, 30	13, 27	11, 25	8, 22	6, 20

	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2011	6 20	3 17	3 17 31	14 18	12 26	23		4 18	1 15 29	13	10

	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2010	7 21 28	4 18	4	1 15 29	13 27	10 24	8 22	5	2 16 30	14 28	2 11	9

	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2009							24	6 20	3 17	8 15 29	12 19	10

Simple containers and views

JimConallen — Thu, 26 Sep 2013 10:37 EDT

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: .
@prefix oslc_viewpoint:     .


    dcterms:title "My Project";
    oslc_viewpoint:viewpoint
        ,
        .


    a oslc_viewpoint:Viewpoint;
    dcterms:title "Use Case View";
    dcterms:description "View of UML Use Cases and Package Hierarchy".
    

    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: .
@prefix rdfs:    .
@prefix ldp:     .
@prefix oslc:    .
@prefix oslc_viewpoint:     .

 
    a oslc_viewpoint:Viewpoint ;
    dcterms:title "Use Case View" ;
    dcterms:description "View of UML Use Cases and Package Hierarchy".


    a ldp:Page;
    ldp:pageOf ;
    ldp:nextPage ;
    rdfs:member 
          ,  
          ,  
          ,  
          ,  
          .  



    a oslc_viewpoint:ViewItem ;
    oslc_viewpoint:resource  ;
    rdfs:label "Resource 1";
    oslc:icon .


    a oslc_viewpoint:ViewItem ;
    rdfs:label "Resource 2";
    oslc_viewpoint:prev ; 
    oslc_viewpoint:children ;
    oslc:icon  .


    a oslc_viewpoint:ViewItem ;
    rdfs:label "Resource 3";
    oslc_viewpoint:prev ;
    oslc:icon  .


    a oslc_viewpoint:ViewItem ;
    rdfs:label "Resource 4";
    oslc_viewpoint:prev ; 
    oslc_viewpoint:children ;
    oslc:icon  .


    a oslc_viewpoint:ViewItem ;
    rdfs:label "Resource 5";
    oslc_viewpoint:prev ;
    oslc:icon  .

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.

Simple containers and views

JimConallen — Thu, 26 Sep 2013 10:36 EDT

Simple Containers and Views

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


@prefix dcterms: .
@prefix oslc_viewpoint:     .


    dcterms:title "My Project";
    oslc_viewpoint:viewpoint
        ,
        .


    a oslc_viewpoint:Viewpoint;
    dcterms:title "Use Case View";
    dcterms:description "View of UML Use Cases and Package Hierarchy".
    

    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: .
@prefix rdfs:    .
@prefix ldp:     .
@prefix oslc:    .
@prefix oslc_viewpoint:     .

 
    a oslc_viewpoint:Viewpoint ;
    dcterms:title "Use Case View" ;
    dcterms:description "View of UML Use Cases and Package Hierarchy".


    a ldp:Page;
    ldp:pageOf ;
    ldp:nextPage ;
    rdfs:member 
          ,  
          ,  
          ,  
          ,  
          .  



    a oslc_viewpoint:ViewItem ;
    oslc_viewpoint:resource  ;
    rdfs:label "Resource 1";
    oslc:icon .


    a oslc_viewpoint:ViewItem ;
    rdfs:label "Resource 2";
    oslc_viewpoint:prev ; 
    oslc_viewpoint:children ;
    oslc:icon  .


    a oslc_viewpoint:ViewItem ;
    rdfs:label "Resource 3";
    oslc_viewpoint:prev ;
    oslc:icon  .


    a oslc_viewpoint:ViewItem ;
    rdfs:label "Resource 4";
    oslc_viewpoint:prev ; 
    oslc_viewpoint:children ;
    oslc:icon  .


    a oslc_viewpoint:ViewItem ;
    rdfs:label "Resource 5";
    oslc_viewpoint:prev ;
    oslc:icon  .

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].

Simple containers and views

JimConallen — Thu, 26 Sep 2013 10:32 EDT

Simple Containers and Views

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


@prefix dcterms: .
@prefix oslc_viewpoint:     .


    dcterms:title "My Project";
    oslc_viewpoint:viewpoint
        ,
        .


    a oslc_viewpoint:Viewpoint;
    dcterms:title "Use Case View";
    dcterms:description "View of UML Use Cases and Package Hierarchy".
    

    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: .
@prefix rdfs:    .
@prefix ldp:     .
@prefix oslc:    .
@prefix oslc_viewpoint:     .

 
    a oslc_viewpoint:Viewpoint ;
    dcterms:title "Use Case View" ;
    dcterms:description "View of UML Use Cases and Package Hierarchy".


    a ldp:Page;
    ldp:pageOf ;
    ldp:nextPage ;
    rdfs:member 
          ,  
          ,  
          ,  
          ,  
          .  



    a oslc_viewpoint:ViewItem ;
    oslc_viewpoint:resource  ;
    dcterms:title "Resource 1";
    oslc:icon .


    dcterms:title "Resource 2";
    oslc_viewpoint:prev ; 
    oslc_viewpoint:children ;
    oslc:icon  .


    dcterms:title "Resource 3";
    oslc_viewpoint:prev ;
    oslc:icon  .


    dcterms:title "Resource 4";
    oslc_viewpoint:prev ; 
    oslc_viewpoint:children ;
    oslc:icon  .


    dcterms:title "Resource 5";
    oslc_viewpoint:prev ;
    oslc:icon  .

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].

Simple containers and views

JimConallen — Thu, 26 Sep 2013 10:30 EDT

Simple Containers and Views

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


@prefix dcterms: .
@prefix oslc_viewpoint:     .


    dcterms:title "My Project";
    oslc_viewpoint:viewpoint
        ,
        .


    a oslc_viewpoint:Viewpoint;
    dcterms:title "Use Case View";
    dcterms:description "View of UML Use Cases and Package Hierarchy".
    

    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: .
@prefix rdfs:    .
@prefix ldp:     .
@prefix oslc:    .
@prefix oslc_viewpoint:     .

 
    a oslc_viewpoint:Viewpoint ;
    dcterms:title "Use Case View" ;
    dcterms:description "View of UML Use Cases and Package Hierarchy".


    a ldp:Page;
    ldp:pageOf ;
    ldp:nextPage ;
    rdfs:member 
          ,  
          ,  
          ,  
          ,  
          .  



    dcterms:title "Resource 1";
    oslc:icon .


    dcterms:title "Resource 2";
    oslc_viewpoint:prev ; 
    oslc_viewpoint:children ;
    oslc:icon  .


    dcterms:title "Resource 3";
    oslc_viewpoint:prev ;
    oslc:icon  .


    dcterms:title "Resource 4";
    oslc_viewpoint:prev ; 
    oslc_viewpoint:children ;
    oslc:icon  .


    dcterms:title "Resource 5";
    oslc_viewpoint:prev ;
    oslc:icon  .

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].

Simple containers and views

JimConallen — Thu, 26 Sep 2013 10:29 EDT

Simple Containers and Views

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


@prefix dcterms: .
@prefix oslc_viewpoint:     .


    dcterms:title "My Project";
    oslc_viewpoint:viewpoint
        ,
        .


    a oslc_viewpoint:Viewpoint;
    dcterms:title "Use Case View";
    dcterms:description "View of UML Use Cases and Package Hierarchy".
    

    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: .
@prefix rdfs:    .
@prefix ldp:     .
@prefix oslc:    .
@prefix oslc_viewpoint:     .

 
    a oslc_viewpoint:Viewpoint ;
    dcterms:title "Use Case View" ;
    dcterms:description "View of UML Use Cases and Package Hierarchy".


    a ldp:Page;
    ldp:pageOf ;
    ldp:nextPage ;
    rdfs:member 
          ,  
          ,  
          ,  
          ,  
          .  



    dcterms:title "Resource 1";
    oslc:icon .


    dcterms:title "Resource 2";
    oslc_viewpoint:prev ; 
    oslc_viewpoint:children ;
    oslc:icon  .


    dcterms:title "Resource 3";
    oslc_viewpoint:prev ;
    oslc:icon  .


    dcterms:title "Resource 4";
    oslc_viewpoint:prev ; 
    oslc_viewpoint:children ;
    oslc:icon  .


    dcterms:title "Resource 5";
    oslc_viewpoint:prev ;
    oslc:icon  .

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].

Structured Views

JimConallen — Thu, 26 Sep 2013 10:04 EDT

Structured Views

Overview

A service provider manages a number of containers of resources. These resources are essentially in a flat space. They typically have relationships with each other. These relationships can be quite complex (especially in modelling space).

There are many cases where a client wishes to present all the members of the container in a structured form for a user to browse through. Containers often have a large number of resources (10’s of thousands to millions) and sending them all to a client in one shot is impractical. A client can receive them all through multiple pages, but this too takes time.

What is being proposed here is a way for a client to request a structured view (structured in the sense of parent child relationships and ordering) of a container. A container may have a default view (canonical ownership), or many other defined views. The view is not just an HTML rendering, but rather a progressive way to get resource titles, icons and child resources in a way that a client can build a native UI.

A client can request the contents of a view (which may have a subset of all the resources). If the view is a typical hierarchy, the first page would contain only the top level resources. If a resource in this response has ‘child resources’ in the view, then an additional property with a link to the child resources is available. The client could provide a user gesture to ‘expand’ that resource. The client would then GET the link and populate the tree control on the client. In this way the user is deciding which resources to fetch and populate the structured view.

Here is an example view from the Rational Design Management web UI

[[Image:WebUITree.png]]

And another example of the same tree in the Rational Software Architect desktop client.

[[Image:RsaTreeView.png]]

The key properties of this view are parent/child relationships and ordering.

Design Requirements

A structured view of a container of resources should not require changes to be made in the domain of the resources
Allow multiple, server defined views for a client to select (and request list of)
Work for large numbers of resources
Client does not have to have any semantic knowledge of the domain of the resources to build a UI for the user
Paging rules similar to existing ones (stable/unstable paging)?

Examples

[[Simple containers and views]]

Related Work

Alternatives Considered

Views are essentially containers. A client can get a list of resource types in container and construct query to get them.

Structured Views

JimConallen — Thu, 26 Sep 2013 10:04 EDT

Structured Views

Overview

Here is an example view from the Rational Design Management web UI [[Image:WebUITree.png]]

And another example of the same tree in the Rational Software Architect desktop client. [[Image:RsaTreeView.png]]

The key properties of this view are parent/child relationships and ordering.

Design Requirements

A structured view of a container of resources should not require changes to be made in the domain of the resources
Allow multiple, server defined views for a client to select (and request list of)
Work for large numbers of resources
Client does not have to have any semantic knowledge of the domain of the resources to build a UI for the user
Paging rules similar to existing ones (stable/unstable paging)?

Examples

[[Simple containers and views]]

Related Work

Alternatives Considered

Views are essentially containers. A client can get a list of resource types in container and construct query to get them.

Structured Views

JimConallen — Thu, 26 Sep 2013 10:01 EDT

Structured Views

Overview

[[Image:WebUITree.png]]

In this way the user is deciding which resources to fetch and populate the structured view.

The key properties of this view are parent/child relationships and ordering.

Design Requirements

A structured view of a container of resources should not require changes to be made in the domain of the resources
Allow multiple, server defined views for a client to select (and request list of)
Work for large numbers of resources
Client does not have to have any semantic knowledge of the domain of the resources to build a UI for the user
Paging rules similar to existing ones (stable/unstable paging)?

Examples

[[Simple containers and views]]

Related Work

Alternatives Considered

Views are essentially containers. A client can get a list of resource types in container and construct query to get them.

Structured Views

JimConallen — Thu, 26 Sep 2013 09:59 EDT

Structured Views

Overview

In this way the user is deciding which resources to fetch and populate the structured view.

The key properties of this view are parent/child relationships and ordering.

Design Requirements

A structured view of a container of resources should not require changes to be made in the domain of the resources
Allow multiple, server defined views for a client to select (and request list of)
Work for large numbers of resources
Client does not have to have any semantic knowledge of the domain of the resources to build a UI for the user
Paging rules similar to existing ones (stable/unstable paging)?

Examples

[[Simple containers and views]]

Related Work

Alternatives Considered

Views are essentially containers. A client can get a list of resource types in container and construct query to get them.

Structured Views

JimConallen — Thu, 26 Sep 2013 09:56 EDT

Structured Views

Overview

In this way the user is deciding which resources to fetch and populate the structured view.

The key properties of this view are parent/child relationships and ordering.

Design Requirements

A structured view of a container of resources should not require changes to be made in the domain of the resources
Allow multiple, server defined views for a client to select (and request list of)
Work for large numbers of resources
Client does not have to have any semantic knowledge of the domain of the resources to build a UI for the user
Paging rules similar to existing ones (stable/unstable paging)?

Examples

[[Simple containers and views]]

Related Work

Alternatives Considered

Views are essentially containers. A client can get a list of resource types in container and construct query to get them.

Structured Views

JimConallen — Thu, 26 Sep 2013 09:54 EDT

Structured Views

Overview

In this way the user is deciding which resources to fetch and populate the structured view.

The key properties of this view are parent/child relationships and ordering.

Design Requirements

A structured view of a container of resources should not require changes to be made in the domain of the resources
Allow multiple, server defined views for a client to select (and request list of)
Work for large numbers of resources
Client does not have to have any semantic knowledge of the domain of the resources to build a UI for the user
Paging rules similar to existing ones (stable/unstable paging)?

Examples

[[Simple containers and views]]

Related Work

Alternatives Considered

Views are essentially containers. A client can get a list of resource types in container and construct query to get them.

Meeting 26 Sep 2013

JimConallen — Thu, 26 Sep 2013 06:48 EDT

Date: 26 September 2013
Time: 7:00 AM Pacific, 10:00 AM Eastern, 3:00 PM UK, 4:00 PM Frankfurt, 5:00 PM Haifa, 8:30 PM Bangalore
Call In Number: (emailed)
Participation request: contact Jim Conallen

Agenda

Update from core workgroup (if Steve available)
Continue discussions of structure lists of resources as used in DM viewpoints and DOORS requirements modules

Active topics

Discuss ongoing work at OMG related to OSLC integration
Structured Views
Link Type Predicates
MDD and Transformations

Attendance

Regrets: John Crouchley, Nir Mashkif

Attendees:

Minutes

Meeting 12 Sep 2013

JimConallen — Thu, 12 Sep 2013 10:58 EDT

Date: 12 September 2013
Time: 7:00 AM Pacific, 10:00 AM Eastern, 3:00 PM UK, 4:00 PM Frankfurt, 5:00 PM Haifa, 8:30 PM Bangalore
Call In Number: (emailed)
Participation request: contact Jim Conallen

Agenda

Update from core workgroup (if Steve available)
Continue discussions of structure lists of resources as used in DM viewpoints and DOORS requirements modules

Active topics

Discuss ongoing work at OMG related to OSLC integration
Structured Views
Link Type Predicates
MDD and Transformations

Attendance

Regrets: Steve Speicher, John Crouchley, Nir Mashkif, Vishwanath Ramaswamy

Attendees: Yuriy Yermakov, David Hirsch, Clyde D. Icuspit, Jim Conallen

Minutes

Brief update on core activities, and short update on current Link Guidance for Core 3.0

Jim presented an update to the structured views, with an example. David pointed out that icons would be useful information to include in the viewpoint response (jim added it).

Simple containers and views

JimConallen — Thu, 12 Sep 2013 10:47 EDT

Simple Containers and Views

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


@prefix dcterms: .
@prefix oslc_viewpoint:     .


    dcterms:title "My Project";
    oslc_viewpoint:viewpoint
        ,
        .


    a oslc_viewpoint:Viewpoint;
    dcterms:title "Use Case View";
    dcterms:description "View of UML Use Cases and Package Hierarchy".
    

    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: .
@prefix rdfs:    .
@prefix ldp:     .
@prefix oslc:    .
@prefix oslc_viewpoint:     .

 
    a oslc_viewpoint:Viewpoint ;
    dcterms:title "Use Case View" ;
    dcterms:description "View of UML Use Cases and Package Hierarchy".


    a ldp:Page;
    ldp:pageOf ;
    ldp:nextPage ;
    rdfs:member 
          ,  
          ,  
          ,  
          ,  
          .  



    dcterms:title "Resource 1";
    oslc:icon .


    dcterms:title "Resource 2";
    oslc_viewpoint:prev ; 
    oslc_viewpoint:children ;
    oslc:icon  .


    dcterms:title "Resource 3";
    oslc_viewpoint:prev ;
    oslc:icon  .


    dcterms:title "Resource 4";
    oslc_viewpoint:prev ; 
    oslc_viewpoint:children ;
    oslc:icon  .


    dcterms:title "Resource 5";
    oslc_viewpoint:prev ;
    oslc:icon  .

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].

Simple containers and views

JimConallen — Thu, 12 Sep 2013 10:46 EDT

Simple Containers and Views

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


@prefix dcterms: .
@prefix oslc_viewpoint:     .


    dcterms:title "My Project";
    oslc_viewpoint:viewpoint
        ,
        .


    a oslc_viewpoint:Viewpoint;
    dcterms:title "Use Case View";
    dcterms:description "View of UML Use Cases and Package Hierarchy".
    

    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: .
@prefix rdfs:    .
@prefix ldp:     .
@prefix oslc:    .
@prefix oslc_viewpoint:     .

 
    a oslc_viewpoint:Viewpoint ;
    dcterms:title "Use Case View" ;
    dcterms:description "View of UML Use Cases and Package Hierarchy".


    a ldp:Page;
    ldp:pageOf ;
    ldp:nextPage ;
    rdfs:member 
          ,  
          ,  
          ,  
          ,  
          .  



    dcterms:title "Resource 1";
    oslc:icon .


    dcterms:title "Resource 2";
    oslc_viewpoint:prev ; 
    oslc_viewpoint:children ;
    oslc:icon  .


    dcterms:title "Resource 3";
    oslc_viewpoint:prev ;
    oslc:icon .


    dcterms:title "Resource 4";
    oslc_viewpoint:prev ; 
    oslc_viewpoint:children ;
    oslc:icon  .


    dcterms:title "Resource 5";
    oslc_viewpoint:prev ;
    oslc:icon .

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].

Structured Views

JimConallen — Thu, 12 Sep 2013 10:00 EDT

Structured Views

Overview

In this way the user is deciding which resources to fetch and populate the structured view.

The key properties of this view are parent/child relationships and ordering.

Design Requirements

A structured view of a container of resources should not require changes to be made in the domain of the resources
Allow multiple, server defined views for a client to select (and request list of)
Work for large numbers of resources
Client does not have to have any semantic knowledge of the domain of the resources to build a UI for the user
Paging rules similar to existing ones (stable/unstable paging)?

Examples

[[Simple containers and views]]

Related Work

Alternatives Considered

Views are essentially containers. A client can get a list of resource types in container and construct query to get them.