Agenda

1. Jim will update the workgroup on core activities.
2. If John Crouchley is present we will discuss a topic he proposed (in earlier email). Some points summarized here. If not we will continue discussion of baselines.

Minutes

Regrets: Brenda Ellis, Andy Berner, Steve Speicher, Dave Johnson, Vishy Ramaswamy, Sandeep Kohli

Attendees: Clyde Icuspit, Dan Berg, John Crouchly, Ran Rinat, Bob Maksimchuk, Scott Bosworth, Tom Piccoli

1. Jim described the recent discussion in the core workgroup related to multi-typed resources. The conversations are far from finished. The workgroup just got to the point where we might need to make the assumption that OSLC resources that are typed (i.e. have rdf:type property) of one of the OSLC domains, then it can be assumed that the resource is in that domain, and expected to meet all the constraints that the domain imposes on resources of that type. Issues still to be addressed include what is the expected HTML response on a get of a multi-typed resource.
2. John introduced the topic for todays meeting; which came out of a Jazz description of how links should be managed. John said that there was an implication that links had backlinks to provide bi-directional visibility.
3. He went on to say that in System Architect, as an OSLC provider they have requirements to expose links in both directions even when 'off-line' (or more accurately when the servers being linked to are not available). This was noted as being a requirement on the System Architect implementation, however we agreed that this is not a requirement of all OSLC AM service providers.
4. Scott pointed out that this topic of back-links has been discussed quite throughly at the OSLC Core level, and the current OSLC Core view of this is that links are simple uni-directional statements. But it is possible for service providers to simultaneously have two links between two resources (pointing in either direction), but that the combination of the two links is NOT considered one thing. In this case it could be considered coincidence.
5. Jim said that for our work group (OSLC AM) that we should not attempt to deviate from the current core recomendations on linking, but rather wait for IBM Jazz team to come to a resoution on the topic, and then wait for the OSLC Core to propose a change to any recommendations before we address this topic again.
6. We all agreed that the current situation (when it comes to Jazz products) is that we have a mix of styles of exposing bi-directional visibility on resource links, and that something should be done to address this, but our workgroup is not the place to do it.
7. Jim went on to discuss some other points about the Jazz documentation and asked if the AM workgroup should define a AM collection, similar to the Requirements Collection that is being defined in the RM specification. The general consensus was that it was not necessary in this domain.
8. Another question was asked related to the idea that it might be useful for a service provider to provide a set of pre-defined queries, and even allow clients to submit custom queries (that could be used and shared by others). Jim took as an action item to propose a stawman implementation of this addition to the services document.