David,

Thanks for the great summary. See Artifact Container Associations for some additional information used for the iotp-adapter.

Project area associations are essentially a convenience used in the jazz apps to allow users to establish a fixed set of dependencies between the service providers of different servers. This provides a convenient means of associating type-specific project areas/service providers that form a scope of related content managers for a complete logical project.

This approach limits the overhead of discovery for common linking operations and limits the project areas listed in selection dialog dropdowns to those that are relevant to users.

Re OR queries for incoming links: the in_op may be used (if supported) to search for many links in a single where clause.  Another possible approach is to get all the triples for which the resource is the object, and then filter out the link types that are not interesting in the client.

To clarify a point Ed made about project area associations in ELM.

For most, but not all , JAF applications in IBM Rational ELM, if you want to create a relationship between artifacts in different project areas, you have to create a project area association of an appropriate type between the “uses” and “provides” project areas. However, there are some applications, such as GCM, where such project area associations are optional. They can be enforced, but are not required by default. Since project areas are not defined by OSLC, non-JAF applications might not implement them, or support the notion of project area associations.

The set of project area association types in ELM is not extensible – they are hard coded in the Foundation process component.

So this mechanism may work well to determine the available project areas for many system-defined link types, but is not a general mechanism for arbitrary links, such as custom link types.

If the incoming links are not supported by a project area association type, you cannot use project area associations to limit the range of your queries. You would have to find all service provider catalogs for all servers of interest (perhaps those defined as friends), and from there the query capabilities for all service providers for a specified resource type. OSLC servers may implement a service provider per project area (or some other storage container concept), and there can be hundreds or even thousands of project areas.

Where a server can determine the other project areas that might be relevant for discovery of incoming links, the next challenge is how to discover the query capabilities associated with those project areas. There are no OSLC defined mechanisms to do this. For example, you cannot determine the OSLC Service Provider catalog URI or the OSLC Service Provider URI for a project area just from a project area URI. A server might make assumptions about how to get the root services document URI from a project area URI (which might only be valid for JAF ELM applications), then discover the SPC, and from there, use OSLC discovery to find the OSLC service providers for those project areas (using a Jazz convention), then the OSLC services, and finally the set of OSLC query capabilities for resources of a specified RDF type. This discovery process may be expensive and may not scale well.

Each query capability should reference a resource shape, which in turn references a value resource shape for the resources being queried. In order for such a query to work, the query capability must support the specific link type URI of interest. A client may be able to check whether the link type(s) are interested in are described by the value resource shape as queryable.  Note that the oslc:queryable property was a recently added feature, and most existing implementations in ELM are unlikely to have implemented it to allow a client to answer the question “can I query for this specified link type”. A property might appear in a  resource shape, but only be selectable but not queryable. If a query expression specifies a property that is not supported by a query capability. the servers is free to either fail the request, or succeed but with the likely outcome that there are no query results.

OSLC query expressions do not support “OR”. So if you want  to discover incoming links of multiple types from the same query capability, you can only do so by issuing a separate query for each such link type. It’s very common in applications like DN and ETM to display multiple incoming link types by default.

As you can see, this is a complex area.

Best regards,
David