Agenda

1. Quickly summarize points from last meeting.
2. Discuss expectations for use of RDF. Can we require or expect clients to interpret resources as RDF?
3. Discuss queryspecification's ability to satisfy needs for specfication

Minutes

Atendees: Alan Yeung, Andy Berner, Brenda Ellis, Ian Green, Jim Amsden, Jonathan Harclerode, Vishy Ramaswamy, Jim Conallen

Jim C. began the discussion around the ability for the current resource format and simple query syntax to support the need to search for resources that have a specific type of relationship to a known target resource URI. This discussion navigated around the way resource links are exposed and managed via generic (and externally defined) properties. The use of the rdf:id attribute and rdf:Description element is used to associate properties to the link itself.

Andy asked if this mechanism would also apply to the OSLC defined properties like title and description. The general agreement was that yes they could also be augmented with the rdf:Description, and that OSLC AM service providers would be expected to support properties this way.

It was also agreed that unless there was a need not to explicitly require RDF/XML format, we should use it and expect it by service providers.

Brenda was concerned that specification, and more accurately the OSLC specifications as a whole, are not addressing access permissions in a cross domain way. She argued that the all the OSLC specification teams should be sharing a common specification for project and access control. Acess control is currently inherenly in the REST apis, and not the resources. There was agreement that this was something that was not currently addressed, something that the OSLC leads should address, and that it was not something that could be solved in the OSLC AM workgroup.

Regarding the resource format, Andy suggested that we make a strong statement indicating the the OSLC AM resource format is not a recommendation on teh actual storage format, just the way the OSLC AM interface exposes AM resources.

The question was asked how links (and properties in general) are added and removed. The simplest approach (but not the only approach discussed), and the only one supported in this specification, is a client must GET the resource format, add or remove properties in the form of RDF/XML elements, then PUT the update back to the server. There was a discussion of the use and scope of ETags. In this specification there is one ETag associated with each AM resource, and whenever a link or property is updated the ETag changes. This is regardless to the fact that the underlying resource and its links and properties may be stored in separate resources. From the client's point of view there is only one current ETag per resource.