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
>
OslcCoreMeetings20100602
(23 Aug 2011,
SteveSpeicher
)
(raw view)
---+ OSLC Core Meeting June 1, 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 Today, I'd like review each of our open issues to make sure we understand them and to see if we can quickly resolve any of them. These are all from the issues page: http://open-services.net/bin/view/Main/OslcCoreV2Issues %RED% Instead of minutes I've added notes in red below based on the discussions we had. %ENDCOLOR% Creation factories #5 Programmatic selection of creation factories. How does a client know which to use to create a resource of a given type? Same goes for delegated UI, and query capabilities. See also: http://open-services.net/pipermail/oslc-core_open-services.net/2010-May/000275.html _Is allowing a creation factory to specify shapes an acceptable solution to this problem?_ %RED% Consensus is that to enable programmatic selection of creation factories and other things, we need a mechanism for identifying services including creation factories, query capabilities and delegated UI dialogs. *Action Item*: Steve Speicher to design mechanism for identifying services %ENDCOLOR% Query capabilities #24 How does client know which property's values are the query results. Is it good enough to let client assume that all property values other than oslc:reponseInfo are query results? See also: http://open-services.net/pipermail/oslc-core_open-services.net/2010-May/000260.htm _Is allowing domains to specify a shape for each query capability an acceptable solution?_ %RED% No opinions were expressed on this topic but I've got a post-meeting comment: so far I've gotten some agreement on the need for a common query resource definition, but also some push-back. We don't need to settle this now because we can always add a common query resource definition to our common resources/properties spec later. *Action Item*: Dave Johnson to TABLE the issue of common query resource definition, we don't put it in the Core spec. %ENDCOLOR% Resource shapes #23 What property do we use to indicate the property that an occurrence of oslc:Property describes? Both rdf:type and rdf:predicate are inappropriate. See also: http://open-services.net/pipermail/oslc-core_open-services.net/2010-May/000250.html #24 How does a service make resource shapes available for its resource, common and customized. Do we host resource shape representations at open-services.net? Do we expect implementations to provide them? _Could we also use oslc:describes here?_ %RED% No discussion. *Action Item*: Dave Johnson to follow-up on which property to use %ENDCOLOR% ---+++++ Common properties #15 Using "dc" for new Dublin Core namespace is unconventional, but changing may break old and misbehaving clients. See also: http://open-services.net/pipermail/oslc-core_open-services.net/2010-May/000256.html _Is Arthur's suggestion of "recommend dcterms, but tolerate dc" an acceptable solution here?_ %RED%We discussed this and consensus is that continuing to use "dc" as we have in the v1 specs is fine, even if unconventional. However, we should make it clear that the old DC namespace URI is deprecated.%ENDCOLOR% ---+++++ Partial Update Good feedback so far, still need to investigate using constrained SPARQL Update and patch document format. ---+++++ Link Guidance Got some good feedback internally and have made some changes in response. Also, got some strong push-back against: * Saying anything about inverse links, strong opposition to inverse links & strong opposition to forbidding them * The need to advise against "link properties" I'm still trying to understand those two issues. I think more consensus building work is necessary. %RED% Lots of discussion about the need for a relationship concept, where each side of a relationships can be represented by a URI property value. Consensus seems to be: nobody suggests that back-links should always be used, everybody agrees that back-links are often used to compensate for lack of cross-product search -- workgroups need guidance on how to model relationships. Also discussed need to annotate relationships. Action Item: Dave Johnson to produce another iteration of Link Guidance and will attempt to address issue of "relationships" and "annotated links". %ENDCOLOR%
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 - 23 Aug 2011 - 13:36:34 -
SteveSpeicher
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