OSLC Core Meeting October 6, 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

• Proposal to add to Appendix A: common properties
  • rdfs:member OSLC domains might define a number of member or contains relationships between resources. The rdfs:member property is suitable for use when only one such relationship needs to be defined, or when no additional semantics need to be implied by the property name.

• Arthur R: "As per my action item, I posted some suggestions for what RDF and HTML should be provided for a namespace URI. I created an example for EMS 1.0. It is incomplete at the moment."
  • http://open-services.net/bin/view/Main/OSLCCoreURINamingGuidance

• OSLC themes and priorities for 2010
  • http://open-services.net/pipermail/oslc-core_open-services.net/2010-October/000597.html

Minutes

Attendees and notes from the meeting

Attendees

• DaveJohnson
• SteveSpeicher
• NickCrossley
• ScottBosworth
• JimConallen
• TackTong
• IanGreen

Topics discussed

• Discussion: rdfs:member: should we add it to common properties
  • Dave J: we use rdfs:member in the examples, and now in OSLC-SCM. It should be in Appendix A
  • Jim C: does this imply some schema meaning that we do not want?
  • Dave J: no, according to Arthur this is not a problem for rdfs:member
  • Tack T: doesn't this impact ongoing implementations?
  • Dave J: no, this should not be a problem, common properties are not required
  • Nick C: your reporting code require shapes now, so you'll find rdfs:member in shapes and should work fine
  • Dave J: should we clarify/explain the use of rdfs:member in the XML examples
  • Ian G: yes, should be specified
  • AI Dave J: add rdfs:member to common properties
  • AI Dave J: propose clarification for rdfs:member

• Discussion: what RDF or HTML should be returned when a namespace URI is dereferenced
  • Scott B: Arthur has done quite a bit of work and it looks pretty complete to me
  • Scott B: He has also provided an XSLT stylesheet to go from RDFS to TWiki syntax
  • Scott B: I think it needs some more review from this group
  • AI Everybody: review Arthur's guidelines

• OSLC 2011 themes & priorities
  • Scott Rich comments http://open-services.net/pipermail/community_open-services.net/2010-October/000328.html
    • Dave J: overview of specifications needed, does this mean presentation, document, tutorial?
    • Steve S: could be those things
    • Dave J: could we reorg the web site start pages to be more friendly
    • Steve S: we could use role based approach like that at OAuth.net, e.g. are you a provider implementor, or a client author?
  • Olivier comments http://open-services.net/pipermail/community_open-services.net/2010-October/000327.html
    • Dave J: Olivier asks for test suites, open sourced
    • Ian G: would be nice to have data driven test suites, see http://fitnesse.org/

• Ian G: does it make sense to be an OSLC core consumer?
  • Jim C: yes, it does. You could create a generic provider
  • Ian G: right, Tack Tong has written such a provider, but how can you get additional meaning?
  • Tack T: my work could be a starting point, but we do not do any creation or update
  • Ian G: would it make sense for a client to advertise itself as a generic client?