OSLC Core Meeting May 26, 2010

Meeting logistics

See the OslcCoreMeetings for more information, more dial-in numbers and on-line meeting information.

• Conference Access
  • Toll free: 1-866-423-8350
  • Toll: 1-719-387-8273
• Participant passcode: 558663

Agenda

No prediction about length of meeting today.

First, I want to to bring everybody up to date on the current state of the spec, which is: all issues RESOLVED!

Here's a summary of the latest round of changes:

• Created OSLC Query Syntax v.Next: this is a snapshot of the Query Syntax part of the OSLC Core spec as of sometime this morning, with all of the features including oslc.from, oslc.offset, etc. It may eventually become the OSLC Core Query Syntax specification.
• Removed features from OSLC Query Syntax v2 spec To further simplify the already simple query syntax, we removed the oslc.from, oslc.limit and oslc.offset URL parameters.
• Added Resource Paging back to Core spec Paging of any resource, and not just query resources, is now back in the Core spec, but clients must specifically request it via oslc.paging=true
• Created OSLC Core Common Properties: this new document is intended to be a "living" registry of common properties used in OSLC resources. OSLC workgroups should consult this list before defining new properties.
• Moved common properties out of Appendix A, leaving only Core properties Core properties are those that are defined in the Core spec or used in the Core spec.
• De-emphasized namespace concept: 1) in the Service Provider resource we now refer to PrefixDefinitions? , 2) when defining a new resource you define a name and a URL and no namespace URI or type URI and 3) when defining a new property you define a name and a URI and no namespace URI or type URI.

And second, if we have time:

• Partial Update Guidance: I've gotten more feedback about the Partial Fetch and Update guidance and my Partial Fetch scheme did not fare well. Instead, as mentioned above, we've added Resource Paging back into the spec. I got good feedback about Partial Update but also a recommendation that I take a second look at SPARQL Update.
• Link Guidance: A first draft of OSLC Core Guidance on Modeling Links is now available for review. It states what I hope are some platitudes about links and then lists the recommended common links, based on work from Steve Spiecher and Ian Green.

Not yet on the issues list:

• Issues from Arthur Ryman: http://open-services.net/pipermail/oslc-core_open-services.net/2010-May/000256.html
• Need for query resource definition (Dave Johnson)
  • We have not defined a data model for a query resource, but we have provided the terminology for them to do so, and they can specify a shape.
  • As things stand today OSLC domain specs will have to specify the data model for their query. They can use OSLC defined resources terminology or a shape to do this, but the result could be a different query representation for each domain.
  • I think this is a problem and my preferred solution to this is to define a simple query shape in Appendix A, make it optional and encourage OSLC domains to use it rather than defining new query data models and representations.

Minutes

• Covered status of spec items
• Encouraged folks to review RESOLVED issues
• Briefly discussed partial update, asked for more feedback.
  • Mentioned that I'll take another look at SPARQL Update as patch format.
• Discussed Link Guidance
  • Jim C: expressed concern about guidance against "link attributes"
  • Jim C: pointed out that the notion of "bi-directional" links is more problematic than "backlinks"
  • Scott B: asked about the issue of "typed names for links" e.g. oslc:relatedChange requests, agreed it should be covered in link guidance
• Discussed Arthur's issues:
  • Shape as a simplified form for the equivalent OWL. Arthur suggests that Resource Shapes could be expressed in OWL and, even if we don't adopt OWL, the exercise of mapping Resource Shapes to OWL could be useful in vetting Resource Shapes.
  • Our use of Dublin Core namespace prefixes seems a little inconsistent with common practice. We are using the new DC namespace, but the old DC prefix. We really should be using "dcterms" as the prefix.
    • Nick Crossley pointed out that this could be disruptive to existing implementations
    • Jim Conallen pointed out that existing implementations may be using the old prefix in query URIs
    • Scott Bosworth suggested getting wider feedback on the issue
    • ACTION ITEM -> Dave to seek feedback on this issue from implementors, others
  • Need for "best practice for services that provide access to resources through both http and https." Should we say anything about how to store URLs when systems may honor both forms of https:// and http://