This wiki is locked. Future workgroup activity and specification development must take place at
our new wiki
. For more information, see
this blog post about the new governance model
and
this post about changes to the website
.
TWiki
>
Main Web
>
OslcCore
>
OslcCoreMeetings
>
OslcCoreMeetings20101013
(22 Oct 2010,
DaveJohnson
)
(raw view)
---+ OSLC Core Meeting October 13, 2010 [[OslcCoreMeetings20101006][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
E
dit
|
A
ttach
|
P
rint version
|
H
istory
: r4
<
r3
<
r2
<
r1
|
B
acklinks
|
V
iew topic
|
Ra
w
edit
|
M
ore topic actions
Topic revision: r4 - 22 Oct 2010 - 18:32:05 -
DaveJohnson
Main
Main Web
Create New Topic
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
Webs
Main
Sandbox
TWiki
Български
Cesky
Dansk
Deutsch
English
Español
Français
Italiano
日本語
Nederlands
Polski
Português
Русский
Svenska
简体中文
簡體中文
Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our
Terms of Use
Ideas, requests, problems regarding this site?
Send feedback