OSLC Core Meeting July 28, 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: changes during past week
  • SHOULD provide RDF/XML
  • Move to final URLs and removal of word DRAFT from specs
  • New home is http://open-services.net/bin/view/Main/OslcCoreSpecification

• Issues from past 24 hours on mailing list
  • oslc:usage: string or URI reference?
    • http://open-services.net/pipermail/oslc-core_open-services.net/2010-July/000439.html
  • oslc:occurs: should be URI (not string) in resource shape?
    • http://open-services.net/pipermail/oslc-core_open-services.net/2010-July/000443.html
  • oslc:isMemberProperty: should it be restored?
    • http://open-services.net/pipermail/oslc-core_open-services.net/2010-July/000440.html
    • http://open-services.net/pipermail/oslc-core_open-services.net/2010-July/000446.html
  • JSON rules: add oslc:results for query results?
    • http://open-services.net/pipermail/oslc-core_open-services.net/2010-July/000444.html

• Finalization!

• Next topics? Candidates:
  • Link Guidance
  • Partial Update Guidance
  • Representation Guidance

Minutes

Notes from the meeting... TBD

Attendees

• MikeLoeffler
• SteveSpeicher
• RobertElves
• JimConallen
• ArthurRyman
• TackTong
• ScottBosworth

Topics discussed

• Status

• Issues from mailing list
  • Using URIs for all identifiers, pros and cons
  • Scott: do we really want a URI for every constant we define? we're not doing this elsewhere
  • Arthur: this is the RDF/LinkedData way, use URIs for identifiers
  • Decision for oslc:occurs: use URIs and Arthur's values
  • Decision for oslc:usage use URIs

• oslc:isMemberProperty
  • Dave: the JSON oslc:results and oslc:isMemberProperty are part of same issue
  • Dave: we took out oslc:isMemberProperty when we simplified shapes, but we went too far
  • Dave: adding it back will solve the JSON issue that Steve pointed out
  • Arthur / Tack: isMemberProperty is needed for a generic query client
  • Add issue: how do we do this in JSON? need to update guidance
  • Scott / Steve: expressed some concern about how oslc:isMemberProperty is supposed to work
  • Decision add oslc:isMemberProperty back to shapes

• Finalization:
  • Dave: I'd like to enter finalization
    • From this point on: corrections and clarifications only
    • Core spec documents should only be edited by myself and one designate
    • Go "final" when we have final domain specs, implementations, etc.
  • Tack: when is the spec to be final?
  • Dave: no specific date, but this should not hold up other specs or implementations
  • Arthur: we should also have some interoperability testing before going final
  • Mike: we need an open reference implementation
  • Scott: yes, that is where we should be
  • Steve: we do review implementation reports in the workgroups
  • Dave: do we need RI for each domain, or just for Core spec?
  • Dave: we need an RI, but there is no hard requirement to have one before Core becomes truly "final"
  • Dave: we have hereby entered finalization!
  • Dave: Thanks to everybody on the workgroup for their great ideas, participation and hard work.
• Dave: next up - closing on our guidance documents, we talk about that next week.
• Arthur: we need new presentation that covers the core spec