OSLC Core Meeting August 25, 2010

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