This wiki is locked. Future workgroup activity and specification development must take place at our new wiki. For more information, see this blog post about the new governance model and this post about changes to the website.
Date: 17 December 2009
Time: 7:00 AM Pacific, 10:00 AM Eastern, 3:00 PM UK, 4:00 PM Frankfurt, 5:00 PM Haifa
Call In Number: (emailed)
Participation request: contact JimConallen

Agenda

  1. Quickly summarize points from last meeting.
  2. Review resource format. Should we declare that resources are RDF?
  3. Review query spec examples. Is the common query spec sufficient?

Minutes

Atendees: Brenda Ellis, Simon Helesen, Dave Steinberg, Scott Bosworth, Nir Mashkif, Jim conallen

  • Jim C. opened the discussion with a review of some comments on the use of the common Simple Query Spec. He said that the query spec could be used to search for resources with certain types of links to specific resources if we could assume or predict that the additional properties in the resource format produced RDF triples.
  • The team discussed the issue of whether or not it was appropriate to state that AM resources are backed by RDF, and that to properly interpret its information we should use RDF. There was some concern over this. While the other OSLC specs imply use of RDF in many places, none come out and explicitly state it.
  • Jim C. proposed that we explicitly state it in the AM spec, so that clients can better interpret or predict the meanings of any additional properties that are added. Unless we do something like this it will not be clear to a client how to query for resources with specific additional property information using the proposed common query syntax.
  • Nir M. asked how links were managed. Jim C. stated that links are created with these simple predicates but PUTing an updated resource back to the server with the new elements in them. Similarly they would are removed by PUTing back a version without them. Consequentally any change in links from a resource also implies a change in the resource state, and hence it will receive a new ETag value and modifed timestamp.
Topic revision: r3 - 17 Dec 2009 - 16:01:09 - JimConallen
 
This site is powered by the TWiki collaboration platform Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use
Ideas, requests, problems regarding this site? Send feedback