- Event details
New Call-in info: https://www.oasis-open.org/apps/org/workgroup/oslc-core/members/action_item.php?action_item_id=3688 (access restricted to OASIS members)
Chat room: http://webconf.soaphub.org/conf/room/oslc
- Roll Call
Approval of Minutes of 1 May 2014
- Next call: 29 May
Namespaces for OSLC-affiliated TCs - Vocabulary URIs
Resource preview updates
Updated with hash resource proposal https://wiki.oasis-open.org/oslc-core/CompactResourceDiscovery#Option3a.3APreferrequestheaderalternative
Discuss Document and Specification Roadmap timetable: +2 months delay (dealing with conferences and summary breaks)
- Any other business
- Arnaud J Le Hors (IBM)
- John Arwe (IBM)
- Arnaud J Le Hors (IBM), Ian Green (IBM), Jim Conallen (IBM), John Arwe (IBM), Sam Padgett (IBM), Steve Speicher (IBM), Harish Krishnaswamy (Software AG)
- Nick Crossley (IBM)
- Minutes of 1 May approved unanimously
- Next TC call will be on 29 May 2014
- Steve Speicher to follow up with Robin on namespaces
- Ian Green to summarize his question on HTTP header in email
Chat transcript from room: oslc
2014-05-15 GMT-08:00 (Timestamps below are US Pacific)
[07:11] Arnaud J Le Hors (IBM): present: Arnaud J Le Hors (IBM) harish (Software AG) ian green jim conallen (IBM) John Arwe (IBM) Sam Padgett (IBM)
[07:11] Arnaud J Le Hors (IBM): Steve Speicher (IBM)
Approval of May 1 minutes
[07:12] John Arwe (IBM): url: https://wiki.oasis-open.org/oslc-core/Meetings/Telecon2014.05.01#Minutes
[07:12] John Arwe (IBM): unanimous approval
Next meeting May 29
[07:13] John Arwe (IBM): It is 2 days before Innovate conference, so some will be traveling
Namespaces for OSLC-affiliated TCs
[07:14] John Arwe (IBM): http://wiki.oasis-open.org/oslc-core/VocabStableURINotes
[07:14] John Arwe (IBM): Was hoping for Robin, no response received that anyone can find.
[07:15] John Arwe (IBM): Tack: form our own opinions and circle around with him
[07:18] John Arwe (IBM): Recap of issues on the wiki page: OASIS policy, Cool URIs Don't Change, options for redirects/ownership
[07:19] John Arwe (IBM): SteveS's preferred option is keep existing namespace URIs (no impact to deployed implementations) and transfer ownership of (at least) open-services.net/ns to OASIS OSLC member section.
[07:20] John Arwe (IBM): ... belief is: one time setup for redirects, from open-services.net URIs to URIs of files residing within OASIS systems, no on-going costs.
[07:23] John Arwe (IBM): Harish: will look into how we handle these things.
[07:23] Steve Speicher (IBM): I tried to summarize my preference, which is mostly the opinion of what I've heard from various TC and WG members https://wiki.oasis-open.org/oslc-core/VocabStableURINotes#Recommendation
[07:23] John Arwe (IBM): Arnaud: any perception problem if IBM continues to fund it wholly, vs the OSLC member section paying? preferences vary
[07:24] John Arwe (IBM): Harish: makes more sense if OASIS pays
[07:26] John Arwe (IBM): SteveS: last time Arnaud/Robin mentioned perception when reading just namespace URIs, people read open-oasis.org and have a certain level of recognition/confidence that might not be as associated with open-services.net
[07:27] John Arwe (IBM): Arnaud: right. notes that as long as open-services.net is live and points to oasis, not necessarily a big deal. as long as people can follow their noses, might be good enough.
[07:28] John Arwe (IBM): SteveS: what do people here think? preferences?
[07:28] John Arwe (IBM): Arnaud: would anyone rather change?
[07:29] John Arwe (IBM): ... meaning change namespace uris for existing vocabularies away from open-services.net
[07:29] Sam Padgett (IBM): +1 on keeping the namespace and transferring ownership of the domain to OASIS if possible
[07:30] harish (Software AG): what are the pros for staying with open-services other than not having to change -
[07:30] John Arwe (IBM): JimC: anyone capable of digging into ownership would know URIs are opaque and not be scared away from using it.
[07:30] John Arwe (IBM): JimC: worried about existing implementations breaking more than perception
[07:32] John Arwe (IBM): SteveS: existing implementations continue working; most deployed ones probably are not expecting redirects, not looking for owl:sameAs
[07:32] John Arwe (IBM): ... allows existing implementations to address new scenarios w/o forking them off too
[07:33] John Arwe (IBM): ...adoption consideration ... it's not progressing especially fast, there are adoptions in progress, why disrupt those
[07:33] John Arwe (IBM): Arnaud: two sides; sometimes name change sends a message
[07:34] John Arwe (IBM): ... agree that impacting the adopters we have won't help anyone.
[07:34] John Arwe (IBM): SteveS: would lead to "oh, when's the next change coming then" questions that are just distractions
[07:35] John Arwe (IBM): ... ala JimC, if existing uris follow good governance, keep using them.
[07:35] John Arwe (IBM): JimC: when dublin core, foaf, etc figure out how to change namespaces for widely deployed vocabularies without disruption, we can follow suit
[07:36] John Arwe (IBM): Action: SteveS to follow up with Robin
Resource preview updates
[07:36] John Arwe (IBM): http://tools.oasis-open.org/version-control/browse/wsvn/oslc-core/specs/resource-preview.html
[07:36] John Arwe (IBM): Sam updated wiki with hash resources info based on last week
[07:37] Sam Padgett (IBM): https://wiki.oasis-open.org/oslc-core/CompactResourceDiscovery#Option3a.3APreferrequestheaderalternative
[07:39] John Arwe (IBM): Turtle is pretty clear. JSON less so; this one does still return info about the resource so 200 OK is fine, but now compact preview is a nested object.
[07:42] John Arwe (IBM): ... JSON purists might wonder why its a nested object, but it's not too bad
[07:43] John Arwe (IBM): Conversations about Location, which is not used on these 200, but was on 209.
[07:43] John Arwe (IBM): ... and about is compact preview same vs different resource and how 3.0 vs 2.0 treatment differs
[07:44] John Arwe (IBM): Ian: in type=oslc-compact responses, what would spec say about the response representation ... how much should it say about the request-uri?
[07:45] John Arwe (IBM): General reluctance to constrain server, example not constraining.
[07:47] John Arwe (IBM): Registration question for preference names
[07:48] John Arwe (IBM): Scribe trouble remembering what w3c ldp had to do, but recommends using the existing preference return=representation with new parameter ala LDP
[07:49] John Arwe (IBM): Sam: hash uri question; if you later try to dereference a hash uri, is the server going to serve it (since that later request would not have the prefer header)?
[07:49] John Arwe (IBM): Arwe: no guarantee
[07:49] John Arwe (IBM): Sam: could use ? uri instead? Arwe: sure.
[07:49] John Arwe (IBM): ... server choice.
[07:50] John Arwe (IBM): Arnaud: do people need more time to think about this? we have not formally agreed that option 3 (some variant) is what we want.
[07:50] Steve Speicher (IBM): 3a is good for me (or 3), fine with either
[07:50] John Arwe (IBM): Arwe: I'm comfy with 3a, continue refining
[07:51] John Arwe (IBM): Ian: confirming we're ok relying on Prefer since it's still a draft.
[07:52] John Arwe (IBM): Arwe: Latest word is RFC editor queue is moving, it will BE assigned an RFC# soon.
[07:53] John Arwe (IBM): Sam: ok with 3 or 3a. do like Prefer header over options 1 or 2. wish json was simpler, of course.
[07:55] John Arwe (IBM): ... one concern is presence of 2 titles with different values. discussion about changing one of them. Ian notes that first one is bug's title, and was chosen "somewhat randomly" i.e. server need not provide that property. Notes that Turtle != JSON.
[07:56] John Arwe (IBM): ... if the JSON was aligned with the turtle in the sense of only returning the type of bug 324 when compact is requested, it would be less confusing.
[08:04] John Arwe (IBM): discussion to align turtle and json more closely, and as a consequence adding <> oslc:compactPreview <#compact> and removing oslc:compacts
[08:06] John Arwe (IBM): Discussion of how PUT works with Prefer; no changes implied.
[08:09] John Arwe (IBM): Discussion of the subtleties of "resource" in http vs rdf.
[08:10] John Arwe (IBM): Jim suggests not using hash URI in this example to avoid the 1:1 vs 1:n issue. Ian suggests using completely opaque uri instead of changing # to ?.
[08:11] John Arwe (IBM): Arnaud: still refining 3a, but seem to be leaning toward 3 or 3a; decide in 2 weeks once 3a is more baked
[08:11] John Arwe (IBM):
Document and Specification Roadmap timetable: +2 months delay (dealing with conferences and summary breaks)
[08:11] John Arwe (IBM):
[08:14] John Arwe (IBM): SteveS: original sketch said goal 3.0 TC drafts end of June, ready for public review. no longer realistic given what we know now (including upcoming conferences); we know August is always a loss from a review standpoint. new target end of august to publish committee draft, but actual date depends on prior review within the TC happening.
[08:15] John Arwe (IBM): ... if anyone has hard dependencies, surface dates. not aware of any at this point.
[08:17] Steve Speicher (IBM): Also saying if anyone has hard dependencies, they should also help drive the spec
[08:17] John Arwe (IBM): Arnaud: LDP going to CR (WG decision made), but that transition must be approved by w3c mgmt so don't have a hard date. Effectively in practical terms it's in CR now, so considered stable enough for implementations. Everyone run out and write code! Test Monday
[08:20] John Arwe (IBM): regrets: nick, (offline - late conflict) martin
Configuration-Context header from Nicks email
[08:20] John Arwe (IBM): chair whines about physics
[08:21] John Arwe (IBM): emails out there
[08:26] John Arwe (IBM): I think only thing Nick was really asking core for was "to prefix with OSLC- or not". Seems like recent IETF deprecation of the X- prefix in registries it governs applies equally to OSLC-, to me.
[08:26] John Arwe (IBM): discussion of is header worth the process overhead or not, opinions vary
[08:27] John Arwe (IBM): SteveS: had not considered link headers, can think about it.
[08:27] John Arwe (IBM): Arnaud: default should be lowest process cost, link header with our uri
[08:28] John Arwe (IBM): Arwe: I would not lay in the tracks over any of the options. If Nick is happy to get the IETF work done, fine.
[08:28] John Arwe (IBM): Arnaud: headers get more scrutiny and usually have to be generally applicable
[08:33] John Arwe (IBM): Ian asks if using Link header interferes with ability to cache based on value of config context uri
[08:34] John Arwe (IBM): Action: Ian to summarize his question in email