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
>
OslcCoreMeetings20100825
(22 Oct 2010,
DaveJohnson
)
(raw view)
---+ OSLC Core Meeting August 25, 2010 [[OslcCoreMeetings20100818][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 * We will review the Link Guidance document and discuss how to finalize it: * http://open-services.net/bin/view/Main/OslcCoreSpecAppendixLinks ---++ Minutes Attendees and notes from the meeting ---+++ Possible Attendees * MikeLoeffler * JimConallen * ScottBosworth * IanGreen * SteveSpeicher * PaulMcMahan ---+++ Topics discussed Discussed terminology Discussed need for guidance on typed links * *Jim C*: what about the fact that a link should be untyped. Isn't it a bad practice to have the type of link built into the link? * *Dave J*: we took out that section because there are many cases where we do need a typed link * *Scott B*: we still have guidance to think carefully about typed links and "ideally anything should be able to link to anything" * *Jim C*: client won't be able to automatically determine the type from information in the link name * *Steve S*: name does not necessarily restrict what is linked to, just what its purpose is * *Jim C*: worried about typing as products evolve. My products implement multiple domains. * *Ian G*: I agree with you Jim, in some cases typed links my be necessary -- we must be pragmatic in cases * *Scott B*: naming of link properties should be left up to domain specs * *Dave J*: Jim has good point about client discoverability of what range is allowed, only ranges * *Jim C*: we should warn clients not to expect certain types as the target of a link * *Jim C*: in an untyped world, we'd have just "related" links and you'd have to query though them to find only comments, or requirements or other types of things Discussed each of the three types of links in the guidance 1) Link No discussion 1a) Link with inlined values of target * *Group*: this form should only be removed because it is really only used in query results. Should not be considered in resource design. It may give the impression that inlined values can be updated via the source resource. * *Dave J*: We should remove this sub-section and example? * *Steve S*: Sometimes it is good to show anti-patterns, what NOT to do * *Scott B*: perhaps we should move this to an anti-pattern section at the end? 2) Anchor * *Jim C*: we should just show the preferred form, not the long form * *Steve S*: I agree, we should remove example #4 and just have #5 * *Scott B*: we should remove the Turtle example too, make things simple * *Dave J*: consider the JSON representation, is it OK * *Steve S*: I'll take a closer look off-line * *Ian G*: are their query implications? The long form RDF/XML seems to make things more clear * *Scott B*: should we provide an example that shows how to query for those annotation values? * *Dave J*: is that right, we need to add a query example? * *Ian G*: not sure how intuitive it is, there should be a clean way -- a single way * *Scott B*: please post that question to the Core mailing list so we can get Arthur's response? * *Ian G*: looking at the JSON example, you would not realize that reification is in use and therefore you would not know how to write a query 3) External * *Dave J*: is the rdf:about correct? * *Ian G*: Should be rdf:about="" and not "#n1" * *Dave J*: this is for annotating a link in a source resource that cannot be modified * *Scott B*: I thought this was for establishing a link between two resources that cannot be modified * *Scott B*: I can't understand the motivation to include this in the guidance * *Scott B*: Perhaps we need guidance on how to establish link between two resources that cannot be modified * *Dave J*: I'm not sure we need this here either, especially if we do not have scenarios/use cases that require it * *Group*: agreed that External Anchors should be removed from the guidance
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:39:20 -
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