OSLC Core Meeting October 13, 2010

Last week's meeting

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

• AI Dave J: add rdfs:member to common properties
  • DONE - http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA#RDFS_Properties

• AI Dave J: propose clarification for rdfs:member
  • NO ACTION - Read over Appendix B section "Specifying the shape of a query result" and with the addition of rdfs:member to common properties, I think we are covered.
    • http://open-services.net/bin/view/Main/OSLCCoreSpecRDFXMLExamples#Specifying_the_shape_of_a_query

• Clarifications sought for Resource Shape oslc:readOnly
  • http://open-services.net/pipermail/oslc-core_open-services.net/2010-October/000600.html
  • RESPONSE:
    • Accept:
      • "true if the property is read-only. If not set, or false, the property is writable."
      • "Providers SHOULD declare a property read-only when changes to the value of that property will not be accepted on PUT. Consumers should note that the converse does not apply: providers MAY reject a change to the value of a writable property."
    • Defer:
      • Give oslc:readOnly is of type xsd:boolean, we adopt the lexical space defined by XSD (true, false, 0, 1).

• Issues with Resource Shape allowed values
  • http://open-services.net/pipermail/oslc-core_open-services.net/2010-October/000603.html
  • RESPONSE: clarify spec to say that allowed values is the union of those specified in-line and out-of-line

• Clarifications sought for oslc:range
  • http://open-services.net/pipermail/oslc-core_open-services.net/2010-October/000601.html
  • RESPONSE: Accept Ian's proposed clarification:
    • "For properties with a resource value-type, Providers MAY also specify the range of possible resource classes allowed, each specified by URI. The default range is http://open-services.net/ns/core#Any."

• Questions about Atom representations of query results
  • http://open-services.net/pipermail/oslc-core_open-services.net/2010-October/000602.html
  • RESPONSE: clarify guidance as follows "OSLC domains should specify whether the content element contains unconstrained RDF/XML or the abbreviated form of RDF/XML that we present in this guidance. Unconstrained RDF/XML should be indicated with content type "application/rdf+xml" and the abbreviated form should be indicated with "application/xml."

• AI Everybody: review Arthur's guidelines
  • RDF/HTML content for our namespace and property URIs
    • http://open-services.net/pipermail/oslc-core_open-services.net/2010-October/000605.html

Minutes

Attendees and notes from the meeting

Attendees

• DaveJohnson
• PaulMcMahan
• SteveSpeicher
• NickCrossley
• ScottBosworth
• PaulSlaunwhite?
• JimConallen
• MikeLoefler?
• IanGreen

Topics discussed

TBD

• AI Dave J: add rdfs:member to common properties

• AI Dave J: propose clarification for rdfs:member

• Clarifications sought for Resource Shape oslc:readOnly
  • Steve S: could also be POST, not just PUT
  • AI Dave J to clarify

• Issues with Resource Shape allowed values
  • Dave J: this looks OK, the most obvious interpretation is the correct one
  • Ian G: then let's clarify
  • Dave J: if this is not a breaking change, then let's make it
  • Steve S: not a breaking change
  • Ian G: not a breaking change
  • AI Dave J to clarify that union is the correct interpretation

• Clarifications sought for oslc:range
  • AI Dave J to clarify using Ian's language
  • Scott B: note that Steve S and I have an active TODO item to review specs an ensure they are using the most appropriate range, which is usually going to be 'any'.

• Questions about Atom representations of query results
  • Scott B: we should make it clear that guidance is for XML, not RDF/XML
  • Dave J: yes, we do not make this clear in the guidance and also in some places in the Core spec itself
  • Steve S: the guidance is valid an useful for those who need to generate RDF/XML or understand how to go from RDF data model to a representation.
  • Dave J: true, but the guidance is for generating RDF/XML and not for parsing it
  • AI Dave J: review guidance, review core - make changes to make the RDF/XML and XML distinction clear
  • AI Dave J: add link annotation to representation guidance for XML

• AI Everybody: review Arthur's guidelines
  • AI Steve S: will do the write up for Core
  • Scott B: we have EM and CM and Core on the way, Ian: when will we see RM?
  • Ian G: should get to it in the near future

• Can we finalize?
  • Steve S: we are close in CM, 3 implementations completing now
  • Ian G: only aware of one provider implementation ongoing, no shape or query implementations yet

• Scott B: we're putting together proposal for open sourcing some OSLC test suites, JUnit-based tests that test a provider implementation. We have questions about the licenses and the location. We like permissive licenses, such as Apache. We like public hosting sites such as Google Code and SourceForge? . We'd like your feedback.
  • Jim C: I prefer SourceForge?
  • Dave J: I prefer Google Code
  • Mike L: either is fine with me, access to code is the most important
  • Dave J: another option, which may be too much overhead, is to incubate an Apache project