OSLC Core Meeting March 4, 2010

Meeting logistics

See the OslcCoreMeetings for telecon number, passcode and online meeting info.

Agenda

• Status
• Comments on spec so far
• The collections issue
• How you can help
• Other issues?
• Quick review of spec concepts (if there is time)

Meeting Minutes

• DaveJohnson
• NickCrossley
• TackTong
• SteveSpeicher
• ScottBosworth
• ArthurRyman
• PaulMcMahan
• Robert Elves

Meeting Minutes

DaveJohnson: Spec lead status

• With Scott's help I now have spec on the wiki
• Guidance on Modeling Links & Partial Update are separate pages
• I've been working to refine the spec language, in particular:
  • Way we describe resources, properties, nesting
  • Way we describe queries
  • Made stab at JSON representation (and got it wrong)
• Met with Tack Tong Aligned Resource Shapes section with Tack's work, need to add examples
• Got excellent comments from Ian Green and Arthur Ryman

DaveJohnson: Comments on spec so far

• Add comments here: http://open-services.net/bin/view/Main/OslcCoreV2Issues
• Ian Green sent useful comments via email
  • better terminology, use some RDF ideas
  • need to spec XML namespaces
  • need to explain idempotence, transactions/changes?
  • should relative URLs be allowed in representations
  • should XML allow xml:base?
  • need guidance of how existing 1.0 specs can migrate
  • worried that Resource Shape == brittle/inflexible, do we want it in core?
  • queries should support POST - need to define String, URI and may need XML Literal
  • not all POSTs need return a Location
  • need to state that ordering is insignificant in representations
  • do we need one required authentication mechanism
  • partial update by command: what are the motivations?
• Arthur Ryman made these comments on the mailing list
  • Need for oslc.properties on resources
  • Need to spec type URI / namespaces
  • Need to spec notion of a Resource Type more clearly
  • rdf:about not a property

DaveJohnson: The Collections Issue - settled?

• • We've decided to use Creation and Query resources instead of AtomPub? -style Collection Resources
  • And to use multi-valued properties instead of Link Collection Resources
  • That's why we are trying to avoid use of the word "collection" because it means AtomPub? collection to some
  • We allow a service to have multiple query resources, each can return subset
  • And multiple creation resources, each can be for a different type of resource
  • The only place we really have anything like a "collection resource" like thing is in query results

• • How folks can help - Review spec carefully and critically
  • Pick a section that needs love, volunteer - Steve S volunteered for Service Resource - Edit the Core spec directly, I'll pick up the pieces

DaveJohnson then reviewed these parts of the spec

• How an OSLC Defined Resource is defined
• In-Line Resource
• Link Resource
• Blog Management example

ArthurRyman: The RDF/XML is not valid, e.g. in dc:creator, there should be an element, foaf:Person, wrapping the property values. The elements in RDF/XML form a "striped" pattern, i.e. as you move from the root element to the leaf elements, the elements alternate between nodes and arcs, i.e. the nodes are resources and the arcs are properties. This introduces some additional elements that an XML designer would not normally use, but the benefit is that if OSLC provides application/rdf+xml resource representations, then these can be automatically indexed by an RDF parser and triple store. Hence the principle of requiring all OSLC specs to provide RDF/XML

ArthurRyman: The <oslc:Query> resource representation should be used when the query is against an entire service (i.e. the entire graph with no distinguished subject node), and <qname>when query is against some subset of all resources determined by a membership property. These are two distinct cases:

• Case 1. The query is sent to a URL that represents the entire graph of triples. The query selects some subset of triple and we need to return these as RDF/XML. The triples could contain information about totally unrelated resources. This RDF/XML for this situation requires the use of an <rdf:RDF> root element and each of the resources in the result become a child element which can either be <rdf:Description> or the qname of the type of the resource, e.g. <oslc_cm:ChangeRequest>
• Case 2. The query is sent to a URL that represents a resource managed by the service. This resource is a node in the graph and we take this as the subject node and then match some subgraph that starts from this node. The result is RDF/XML that has a root element that is the qname of the type of the URL, i.e. the RDF/XML of the query result has the same XML root element as we would get if we simply did an HTTP GET on the URL.

ArthurRyman: The principles of REST design say that resources should not be verbs like get or query or create, but nouns. The notion of an AtomPub-style collection is useful, a place where you post items and then you can get back items of that same type. Well-designed REST URLs represent things and HTTP provides the verbs that act on those things. Therefore if you are designing URLs that represent actions, then you are not following REST principles. A common pattern in REST is to create new resources by POSTing to a URL which represents a set of resources, i.e. you add a resource to this set by POSTing a representation to it. In RDF terms, you can model this URL as having a membership property that relates it to the resources that were created by POSTing to it. This URL is therefore like a collection or container or list or set, and when you GET this URL it is natural to receive a list of its members, e.g. like a directory listing. Since this list could be very long, the server should chunk it into pages, e.g. like in Atom or RFC 5005. Query parameters then provide a way to search for specific members of this set, i.e. they filter the set of resources.