History   View   Links to this page 2013 March 13 | 07:20 pm

OSLC Core Meeting March 13, 2013

Previous meeting

Meeting logistics

Included in Meetings

Agenda

Review Minutes from Feb 27

Reconciliation is requesting to go final

  • 5 implementations ( listed in [1] )
    • 4 releasing in 1Q2013, 1 releasing in beta now, releasing in 3Q2013.
    • 3 more implementation reports from business partners to be added in next 2 weeks, all releasing in 1Q2013
    • all implementors participated in one verification test using the same server
  • No Lyo test suite - I’ve broached the subject with John A. and Steve.
    • Current point of view is that for this version of the spec, we already have implementors that have gone through product test
      • one wg member (jazz for Service Management) has committed a person to implement a Lyo test suite in 2Q2013
      • same WG member is discussing sharing verification code with the WG

[1] http://open-services.net/wiki/reconciliation/OSLC-Reconciliation-Implementation-Reports-2.0/

Update on TRS

  • SDK, reference implementation contributed to Lyo
  • Requesting TRS to be considered “in convergence”. Any -1s?

OSLC Core V2 Issues - Outstanding issues and proposed updates

  • No new issues
  • Issue 42
  • Call to WG members to close out any issues that appear to be “OPEN”. Think some are complete but paperwork (updating wiki page of issues) hasn’t been completed.

V3 Spec Drafting - OSLCCoreSpecificationsV3

  • Delegated resource editors:

    • Steve recommends Ed send out a oslc-core email to help define the scenario and outline requirements for the solution.

  • Updates PATCH support - looking at named graph syntax to support model

    • Approach has been presented to the W3C LDP workgroup. Working through the feedback

  • Use cases and requirements for vocabulary definitions going forward and a proposal

Next meeting:

  • Mar 27 - EclipseCon, reschedule?

Open / future topics:

  • EdGentry suggested topic: Pickers: with preferred or restricted link types, limiting what can be selected or linked to resource type. SteveS suggests submitting the scenario + some details to either RM (or other appropriate WG) or Core to seed the discussion.

  • NickC suggested topic: need to extend the OSLC pickers (and other areas possibly like query) to allow a [configuration] context to be passed, so the provider can show the versions/variants of the resources in that context, and so the resulting link preserves that context.

Minutes

Next meeting: * Mar 27 - EclipseCon, reschedule? Was left un-addressed

Attendees

Attendees: MichaelFiedler, TuanDang, NickCrossley, PaulSlauenwhite, EdGentry, ArthurRyman, JimConallen

Regrets: SteveSpeicher, JohnArwe, PaulMcMahan

Discussion

Reconciliation

  • Reviewed request to be declared final
  • No concerns
  • TODO: MichaelFiedler will send e-mail to core, community and steering committee with last call for comments
  • Target: Declare final in next workgroup meeting on 27 March

TRS

  • Reviewed request to be declared in convergence - no objections
  • Reviewed Eclipse Lyo contribution

Delegated resource editors

  • EdGentry took the TODO to document scenarios and proposed approaches
    • What can be done with tweaks to current dialog definitions vs. more advanced approaches like Open Social

Partial Update/PATH discussion

  • Examples with blank nodes need more work - will not function as currently laid out
    • Need to use variables instead of blank node IDs
  • General sentiment (Arthur, Nick, Jim) that OSLC might be better served by not trying to “dumb down” the SPARQL update syntax
    • does not imply providers need to implement full SPARQL update functionality, limits/constraints are fine
    • reminiscent of other efforts to adopt subsets of RDF

Link guidance discussion

  • Need for further discussion on this topic - schedule as future topic
    • Some implementers concerned about performance want specs to adopt the “single link” guidance ASAP
  • Crux of the conversation: How do we give guidance to spec authors and implementers on how link directions should be defined (Verb vs VerbedBy). Considerations:
    • User expectation or natural semantics of link direction
    • performance of queries
    • Which link directions are more natural in presentations such as reports or UIs
  • Need for updating simple query syntax to encompass named graphs (also related to VVC)
  • Core needs to help domain specifications with relationships determine where the relationship predicate belongs