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
>
OslcCoreMeetings20100728
(30 Jul 2010,
DaveJohnson
)
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
E
dit
|
A
ttach
|
P
rint version
|
H
istory
: r4
<
r3
<
r2
<
r1
|
B
acklinks
|
R
aw View
|
Ra
w
edit
|
M
ore topic actions
Topic revision: r4 - 30 Jul 2010 - 13:25:08 -
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