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 6 March 2014
- Next call: 3 April
- Resource/UI preview
- Using just plain old JSON, providing static @context for json-ld
- New term 'compacts' to link compact doc to the resource it is providing preview for
- Use of 'Prefer' request header instead of custom content type, following LDP's lead
- How does a client discover a server supports UI preview on a resource? HEAD/OPTIONS and will get some Prefer response?
- Any other business
- Arnaud J Le Hors (IBM)
- Ian Green (IBM)
- Arnaud J Le Hors (IBM), Bill Chown (Mentor Graphics), Harish Krishnaswamy (Software AG), Ian Green (IBM), John Arwe (IBM), Lin Ju (IBM), Sam Padgett (IBM), Steve Speicher (IBM), Martin Pain (IBM)
- Minutes of 6 March approved unanimously
Chat transcript from room: oslc
2014-03-20 GMT-08:00 (Timestamps below are US Pacific)
[07:14] Arnaud J Le Hors (IBM): Roll call: Arnaud J Le Hors (IBM) Bill Chown (Mentor Graphics) Harish K (Software AG) ian green John Arwe (IBM) Lin Ju (IBM) Sam Padgett (IBM) Steve Speicher (IBM)
Approval of minutes of last meeting (March 6)
[07:15] ian green: minutes march 6th: approved
[07:15] Steve Speicher (IBM): FYI https://wiki.oasis-open.org/oslc-core/Meetings/Telecon2014.03.06#Minutes
[07:17] ian green: next call 2 in weeks, april 3rd.
Spec authoring & Editor's handbook
[07:18] Steve Speicher (IBM): https://wiki.oasis-open.org/oslc-core/SpecWriterHandbook
[07:20] ian green: Steve gives overview of the SpecWriterHandbook. Looking for feedback on this page.
[07:21] ian green: Is it useful? are there gaps? suggestions for improvement welcome.
[07:21] ian green: Good place to start if there are questions relating to spec. development
[07:24] ian green: Includes ref to the LDP's group on terminology around stories, uses cases, requirements. we ought to strive for some consistency across our work
[07:24] ian green: Steve has continued to spend time on ReSpec investigation
[07:26] ian green: Steve gives brief overview of what ReSpec offers. Steve has removed some w3c-specific stuff
[07:27] ian green: Some initial work from Sam and Steve on current wip for TC spec. documents
[07:27] ian green: Using this OASIS ReSpec branch
[07:28] ian green: We now subversion for use by this TC, available from TC home page.
[07:28] ian green: Folks use OASIS credentials. Steve to confirm this works.
[07:28] jim conallen (IBM): looks like that link in the email provides a web ui for the repository
[07:29] ian green: Q from Arnaud: is there any reason that we would not use ReSpec? A. Steve, can't see any reason why not.
[07:30] ian green: Steve: there are some differences in versioning schemes, copyrights. Steve is optimistic it can fit the model OASIS has.
[07:31] ian green: Work in progress is to be pushed to subversion repo. (Not yet available on wiki)
[07:32] ian green: Sam is working on this document. He will push to svn soon
[07:33] Martin Pain (IBM): (I just joined)
Using just plain old JSON, providing static @context for json-ld
[07:34] ian green: Current proposal is for ui preview to be json. suggestion is that json-ld clients might also be supported
[07:36] ian green: Observation that json-ld might be overly verbose for consumers not interested in the ld part
[07:36] ian green: Discussion about how the resource representation can be acceptable to different consumers, without forcing json-ld on everyone
[07:37] ian green: Arnaud - (but) the value is to use the standard
[07:38] ian green: Arnaud - but the context is needed to make sense of that json in ld context.
[07:41] ian green: Arnaud - we should not stray into a middle ground where non-json-ld consumers want some ld features.
[07:42] jim conallen (IBM): Can we at least state that we should not produce a specification that would not be supported by JSON-LD. That is, clients that want to use JSON-LD should not have to be prepared to jump to generic JSON on ocassion.
[07:42] ian green: Sam - we may already have done this/
[07:44] ian green: Steve (resp. to JC) we might need to place constrains on the json-ld (subset thereof).
[07:44] Steve Speicher (IBM): +1 Jim, we should be compliant with JSON-LD and that is what we were proposing
[07:45] ian green: Steve: do we need to talk about other resource formats?
[07:45] ian green: Steve: we also need guidance on dual support for oslc-v2
[07:46] jim conallen (IBM): imho: no ... we have far to many formats/variants in our specs as is. JSON is easy, everyone can do it. anyone who complains should be taken out and shot
[07:48] ian green: All agree that JSON(LD) is the must, others of course optional
[07:50] jim conallen (IBM): JSON is a MUST, others optional using standard content negotiation. We want to also ensure that JSON-LD clients woudl work.
[07:52] ian green: Discussion about whether the representation should be split into separate resources
New term 'compacts' to link compact doc to the resource it is providing preview for
[08:00] ian green: Discussion about the rdf model of the ui preview representation
[08:04] ian green: Martin - is the ui preview an informational resource?
[08:05] ian green: Martin - the subject of the triples would need to be specified.
[08:06] Sam Padgett (IBM): 2.0 UI preview spec: http://open-services.net/bin/view/Main/OslcCoreUiPreview
[08:06] ian green: Arnaud - TAG expressly cautions that distinct resources ought to have distinct uris
[08:06] Sam Padgett (IBM): "The oslc:Compact element MUST be a child of the root element and MUST specify an rdf:about attribute whose value is the URI of the target resource."
[08:06] John Arwe (IBM): FYI, there's a TAG draft (WIP, not finished) on this set of issues: http://www.w3.org/2001/tag/doc/urls-in-data-2013-04-27/
[08:07] jim conallen (IBM): So Arnaud, are you saying that we have one URI for the resource, and that every GET of that resource returns an equivalent content (diff formats but exact same content). We use different URIs to get representations that are not equivalent (html, image/*, ...)
[08:10] ian green: All agree that ui preview and the underlying resource are different
[08:11] jim conallen (IBM): as well as full html views. So there is URI of a resource, it contains RDF data - period. Then there are other resources that provide different renderings of that resource in HTML, image, ...
Use of 'Prefer' request header instead of custom content type, following LDP's lead
[08:13] ian green: Sam describes options for discovering ui preview support
[08:14] ian green: One option is to use http link header
[08:14] ian green: another is to use http Prefer
[08:17] ian green: Desire to avoid using specialized content-type
[08:17] ian green: but to avoid additional round-trip
Any other business
[08:19] ian green: No other business
[08:20] ian green: Arnaud - Nothing to report on the use cases document.
[08:21] ian green: Steve - document owners should look to see what's ahead and have review at the next call.
[08:21] ian green: Arnaud proposes adjourn
[08:21] ian green: cheerio