OSLC Core Meeting May 12, 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

Status

• Specification reorganization

Issue discussion

• Open issues (from issues page)
  • Proposed query simplifications?
  • Moving Resource Shapes to Appendix A?
  • Where are we on Specification Versioning?
  • Removing namespace declarations from JSON reps?
  • Allowed values changes: fix and add min/maxes?
• Other issues (not yet on issues page)
  • dc:contributor: sometimes a foaf:Person, sometimes a software package?
• If we have time: New partial update guidance draft: OSLC Core Partial Update DRAFT

Proposal

• Scratch the May 26 finalization date and finalize when we have more adoption/implementation

Meeting Minutes

Attendees

• DaveJohnson
• RobertElves
• AlainPicard
• ArthurRyman
• ScottBosworth
• NickCrossley
• SteveSpeicher
• PaulMcMahan

Status

DaveJohnson: we have reorganized the Core spec, broken out the appendixes and query syntax into separate wiki pages, but these separate wiki pages are still considered part of the core.

DaveJohnson: Scott, Steve and I met last week to discuss query, shapes and other issues and generated about 10 new issues with the Core spec. These are captured on the OSLC Core issues page.

Issues

DaveJohnson: We're getting feedback that the query spec is too complex, too large, too different from the v1 query, so perhaps we should simplify by dropping oslc.from, oslc.prefix, oslc.limit and oslc.offset? What do others think?

• ScottBosworth: "not finalizing" is probably better way to express this instead using the term dropping
• ArthurRyman: there are valid use cases for these things. Why can't we get some implementation experience, then decide what to drop?
• SteveSpeicher: we implemented limit in v1 specs
• ScottBosworth: we should table this discussion until SteveSpeicher takes a closer look at query use cases
• Action -> table this for now

DaveJohnson: some of the feedback we're getting on the Core spec indicates that people see the Resource Shape section in the outline, and some think that we are trying to solve an impossible problem, reinvent OWL, reinvent XML schema, etc.

• ArthurRyman: what we're doing is providing our OSLC Defined Resource definitions in a machine readable form
• DaveJohnson: agreed. What I'm proposing is purely cosmetic. To make the spec less threatening and more digestible, move Resource Shapes to Appendix A where we talk about common properties and resources.
• ArthurRyman: Resource Shapes need to be normative, not just informative examples
• SteveSpeicher and DaveJohnson: appendixes can be normative
• Action -> move Resource Shapes to Appendix A

DaveJohnson: we specify the namespaces and prefixes in the Service Resource, can we leave namespace definitions out of our JSON representations because they are redundant?

• IanGreen: what about scenarios where namespaces are dynamic, and new ones may be introduced in new resources. We still need to be able to query and represent properties with namespaces that are not pre-defined or specified in a Service Resource. Will clients have to reparse the Service Resource constantly to keep up with new namespaces?
• Action -> Dave to follow up on this issue

DaveJohnson: allowedValues does not allow min/max values, should we add this?

• ArthurRyman: XML schema supports this, should we ask folks to use it instead in some cases? Seems like we are re-inventing XML schema, where do we stop?
• DaveJohnson: since we are trying to simplify and drop things from query, perhaps we should not be adding new things to resource shapes.
• Action -> Fix allowedValues, but don't add min/max

DaveJohnson: sometimes dc:contributor is a person, sometimes a software package

IanGreen: can we se dc:publisher in Service Resource instead?

Action -> Dave to look into dc:publisher or oslc:Contributor as an alternative to dc:contributor in service resources

DaveJohnson: I would like to propose that we postpone finalization until we have more experience with adoption and implementation and reconsider the question later, July possibly.

• ScottBosworth: OK, but make it clear that we are in convergence -- we will only be fixing things, not adding new. We want folks to start implementing and not to worry that things are still in flux.
• DaveJohnson: yes, we should make this clear. One thing that can help is to remove the DRAFT label from the Core spec and the associated URIs.
• Action -> postpone finalization, remove DRAFT label from Core Spec, add language explaining convergence at start