Next in thread →
Next in month →
Re: [oslc-core] Discovery scenarios (LDPCs)
Jim, Did you say you would be working through how SPCs, SPs and Services can be LDPCs? Just checking in now that we're half way between the meetings. One thing that comes to mind to warn about, is that it would be easy to say "Services are LDPCs of the domain resources" (that is, the resources for which the v2 vocab has creation factories, query capabilities, dialogs, etc), but it's not as simple as that: We don't have the data to say whether or not that is compatible with v2 implementations (in fact, the one implementation that I'm very familiar with - my own - models the Service as if it had three "containers" in it - see the automation examples on the wiki page. However, that doesn't mean that it will be incompatible to model them as one LDPC if/when moving to v3.) v2 clients will be expecting each Service resources to be a "Local Resource" - if they are strict to the v2 spec as written, then they will be expecting a blank (anonymous) node. At very least they will be expecting it to be inline. To allow a Service resource to be an LDPC, then it needs a "Link ...; rel=type" header, and you can't provide them for blank nodes (and to provide them for URIs with fragments (hash identifiers) you would need to use the "anchor=" parameter on that header, for which I've not seen a precedent with LDPCs). Martin Pain Software Developer - Green Hat Rational Test Virtualization Server, Rational Test Control Panel E-mail: Find me on: and within IBM on: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU __________________ Just to clarify something about that wiki page that I didn't mention at the meeting: I was not intending to consider alternatives in those examples, except one question: whether or not they are LDPCs (and if the spec says that they MAY be LDPCs, then they are all consistent with respect to one option of what the spec could say - as whether or not they are LDPCs would be an implementation decision). Both sets of examples are built on the option of the spec saying: that servers MUST use the OSLC v2 vocab and (if they are providing discovery ) MUST provide an SPC, and that they MAY also make those discovery resources LDPCs.(However, that approach as specified by me here is under-specified, as it does not define how they would be LDPCs, therefore I think it is not that useful for a client). Where the examples change the representation of a resource from a previous example, this is where it is iteratively building it up as a thought process starting from the lowest level and going up. It is not changing the option of what we can put in the spec. Some of these iterations are at the server's discretion - e.g. making the resources LDPCs - so there are multiple variations in the examples, but they are all variations that servers could legitimately choose if the spec took the option described above. I updated a little bit of the wording on the wiki page to make that clearer (or to correct where I hadn't quite followed that approach) but the content is the same. Martin Pain Software Developer - Green Hat Rational Test Virtualization Server, Rational Test Control Panel E-mail: Find me on: and within IBM on: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU From: "Jim Amsden" <> To: OASIS <> Date: 03/09/2015 14:48 Subject: Re: [oslc-core] Discovery scenarios (LDPCs) Sent by: <> Martin, Thanks for the clarification. Regarding your points: 1. LDP based discovery only addresses capability not URI/resource discovery: I don't see LDP based discovery or SPC based discovery as any different in this regard. Both require the client to have knowledge of at least one distinguished URI that is the root of the discovery tree - an LDPC and/or an SPC resource - and the current proposal is that these are the same thing, making the difference in the approaches even less. So I see URI discovery as a separate issue shared by both V2 and V3. 2. Being aware of the consequences of our decision Yes, agree. For example, if ServiceProvider and Service resources have rdf:type ldp:Container, and the oslc:service property of ServiceProvider has oslc:representation oslc:Inline, then that should means that a GET on a ServiceProvider provides the same resource representation in V3 as it did in V2. This would be an extension to LDP for OSLC. So a server could provide a single ServiceProvider that provides all the Services information a client might need in a single resource representation. As another example, if a Service in an LDPC, servers could decide whether that LDPC also supports resource creation, creation and selection dialogs and/or query. If not, then the OPTIONS on that LDPC wouldn't return the discovery Link headers, and the properties of the Service resource would reference other LDPCs that do support incremental discovery. But you are correct - we need to work through a set of client and server use cases and supporting examples that demonstrate and validate V3 discovery. One way to facilitate that might be to pick a draft proposal and work that through the use cases to identify any problems, missing capabilities, inefficiencies, or issues. We learn from that, adapt the proposal (or scrap it and create a new one) and try again. That might be easier to follow than exploring a number of different approaches on the same use case at the same time. Jim Amsden, Senior Technical Staff Member OSLC and Linked Lifecycle Data 919-525-6575 From: Martin P Pain <> To: Jim Amsden/Raleigh/IBM@IBMUS Cc: OASIS <> Date: 09/03/2015 09:11 AM Subject: Re: [oslc-core] Discovery scenarios (LDPCs) Sent by: <> Quick responses (bold text to make scanning easier): 1. Using LDP, and the Link headers on LDP, was not questioned by these scenarios. I agree we have settled on using them. However, as I've said before, they only deal with capability discovery not URI/resource discovery (of those LDPCs), which is one thing that SPCs, SPs etc provide. That walk through & examples of how servers think about discovery focuses on that kind of discovery (which can also describe capabilities such as creation, which is why that is included). So that walk-through and those examples consider how & whether we should make SPCs etc into LDPCs. 2. I agree that we need to look at it from the client's point of view as well, but we need to make sure it makes sense when servers implement it too. Also, we need to be aware of the consequences of any decisions we make here, which I don't believe we can do properly without worked examples such as these. Such as, if we enforce that SPCs are LDPCs, then that means servers can't do the one-resource-for-everything for simple cases as in the examples for scenario A. Also, the consequences of limiting the relationship between Service resources and the LDPCs of domain resources - taking the case of OSLC Automation as an example, where there are three resource types which servers may want to be in separate LDPCs, but which need to be in the same Service. I hope that clarifies what I want to get out of that wiki page. I think I hadn't made my intentions for why I was doing that work clear. Martin Pain Software Developer - Green Hat Rational Test Virtualization Server, Rational Test Control Panel E-mail: Find me on: and within IBM on: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU From: "Jim Amsden" <> To: OASIS <> Date: 03/09/2015 03:01 Subject: Re: [oslc-core] Discovery scenarios (LDPCs) Sent by: <> My understanding is that the decision point was not whether OSLC 3.0 Core uses LDPCs for discovery or not, its whether we unify OSLC2 and OSLC3 discovery by making ServiceProviderCatalog, ServiceProvider, and possibly Service include rdf:type Container. Building OSLC 3 on LDP was fundamental to the value proposition of OSLC 3 standardization. Unless there are use cases that cannot be supported, isn't discovery based on LDPCs and Link headers a settled decision? We've also agreed that OSLC2 discovery has to be supported for backward compatibility. That requires OSLC3 to include ServiceProviderCatalog, ServiceProvider and Service classes (and their associated properties) in the vocabulary. The question we're trying to resolve is how these fit together. Can they be merged so clients can have document centered up front, or dynamic incremental discovery, which ever meets the application needs. Since discovery is provided by a server in support of clients, we should examine discovery from the demand side too - what the clients need and demonstrate how the services are able to provide it efficiently and effectively. Jim Amsden, Senior Technical Staff Member OSLC and Linked Lifecycle Data 919-525-6575 From: Martin P Pain <> To: Martin P Pain <> Cc: OASIS <> Date: 09/02/2015 09:19 AM Subject: Re: [oslc-core] Discovery scenarios (LDPCs) Sent by: <> I've added the examples to this page, and finished the walk-through of how servers think about discovery: https://wiki.oasis-open.org/oslc-core/Discovery/Scenarios#How_servers_think_about_discovery Ideally this would also then need to look at how clients consume those examples, to validate that they are useful, and what if any value there is in using LDP at each layer. However, I have just realised that my examples are not compatible with OSLC v2, as I've made the oslc:Service resources separate resources with their own URIs, whereas the v2 spec requires them to be "Local Resources" (for which it says "i.e. blank nodes", but I think the intention was to allow hash URIs as well - but I may be wrong). But I don't have time to correct this now. I any case, it would be good if you could all have a look at the "How servers think about discovery" half of that page before the meeting tomorrow (although I admit it's not easy to scan - sorry). I suggest we walk through this page at that meeting to bring us to a decision on whether we use LDPCs in discovery or not. Martin Pain Software Developer - Green Hat Rational Test Virtualization Server, Rational Test Control Panel E-mail: Find me on: and within IBM on: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU From: Martin P Pain/UK/IBM@IBMGB To: OASIS <> Date: 28/08/2015 17:03 Subject: [oslc-core] Discovery scenarios (LDPCs) Sent by: <> I've added most of the work I've done so far on thinking through discovery using LDPCs here: https://wiki.oasis-open.org/oslc-core/Discovery/Scenarios So far there is: A walk through of how OSLC Automation discovery works in v2 The first half of thinking about how a server using LDPCs would want OSLC discovery to work I'm also intending to fill in the third column of the table with how a client would take advantage of LDPCs having been used in discovery (although of course such a client would not be compatible with v2 servers unless they programmed the v2 approach anyway). I've also got some worked examples to go with the "servers" section, which I haven't worked into the wiki page yet, but I'll copy them here so you guys have a chance to see them, think about them, comment on them etc in good time for Thursday. Please have a read through all of this (in particular the servers section on the wiki page an the examples below) and think about whether this is how you would expect OSLC discover to work with LDPCs, and whether LDPCs give us (or anyone) any benefits. Here are the examples, but you'll have to correlate them to the text in the wiki page yourself for now. These examples are not complete in that they don't go as far as Service Providers or SPCs, but as far as creation factories & services are concerned I don't have any further changes in mind (although there probably are more scenarios that could be covered). Scenario: Server contains one LDPC, with one resource type. LDPC: GET /discovery HTTP/1.1 Host: example.com 200 OK Content-Type: text/turtle Link: http://www.w3.org/ns/ldp#BasicContainer; rel="type", <http://www.w3.org/ns/ldp#Resource>; rel="type" @prefix dcterms: <http://purl.org/dc/terms/>. @prefix ldp: <http://www.w3.org/ns/ldp#>. <> a ldp:BasicContainer; dcterms:title "Container of all this server's resources (which are all of one type)"; ldp:contains </r1>, </r2>, </r3>. Plus Creation Factory: GET /discovery HTTP/1.1 Host: example.com 200 OK Content-Type: text/turtle Link: http://www.w3.org/ns/ldp#BasicContainer; rel="type", <http://www.w3.org/ns/ldp#Resource>; rel="type" @prefix dcterms: <http://purl.org/dc/terms/>. @prefix ldp: <http://www.w3.org/ns/ldp#>. @prefix oslc: <...>. <> a ldp:BasicContainer, oslc:CreationFactory; dcterms:title "Container of all this server's resources (which are all of one type)"; ldp:contains </r1>, </r2>, </r3>; oslc:creation <>; # Itself oslc:resourceType <http://example.com/resource-type>. # Optional Plus Service: GET /discovery HTTP/1.1 Host: example.com 200 OK Content-Type: text/turtle Link: http://www.w3.org/ns/ldp#BasicContainer; rel="type", <http://www.w3.org/ns/ldp#Resource>; rel="type" @prefix dcterms: <http://purl.org/dc/terms/>. @prefix ldp: <http://www.w3.org/ns/ldp#>. @prefix oslc: <...>. <> a ldp:BasicContainer, oslc:CreationFactory, oslc:Service; dcterms:title "Container of all this server's resources (which are all of one type)"; ldp:contains </r1>, </r2>, </r3>; oslc:domain <http://example.com/custom-oslc-domain>; oslc:creationFactory <>; oslc:creation <>. Scenario: Automation - with separate LDPCs for AutoPlans, AutoRequests & AutoResults (another option would be to have one LDPC for all 3 types): LDPC: GET /autoPlans/ HTTP/1.1 Host: example.com 200 OK Content-Type: text/turtle Link: http://www.w3.org/ns/ldp#BasicContainer; rel="type", <http://www.w3.org/ns/ldp#Resource>; rel="type" @prefix dcterms: <http://purl.org/dc/terms/>. @prefix ldp: <http://www.w3.org/ns/ldp#>. <> a ldp:BasicContainer; dcterms:title "Tasks available for execution"; ldp:contains </autoPlans/1>, </autoPlans/2>, </autoPlans/3>. Very similar for /autoRequests/ and /autoResults/. Plus Creation Factory: GET /autoPlans/ HTTP/1.1 Host: example.com 200 OK Content-Type: text/turtle Link: http://www.w3.org/ns/ldp#BasicContainer; rel="type", <http://www.w3.org/ns/ldp#Resource>; rel="type" @prefix dcterms: <http://purl.org/dc/terms/>. @prefix ldp: <http://www.w3.org/ns/ldp#>. @prefix oslc: <...>. @prefix oslc_auto: <...>. <> a ldp:BasicContainer; dcterms:title "Tasks available for execution"; ldp:contains </autoPlans/1>, </autoPlans/2>, </autoPlans/3>. _:factory a oslc:CreationFactory; oslc:creation <>; # The request URI oslc:resourceType oslc_auto:AutomationPlan. Service: GET /automation/ HTTP/1.1 Host: example.com 200 OK Content-Type: text/turtle @prefix dcterms: <http://purl.org/dc/terms/>. @prefix oslc: <...>. <> a oslc:Service; oslc:domain <http://open-services.net/ns/auto#>; dcterms:title "Task automation"; oslc:creationFactory [ oslc:creation </autoPlans/>; oslc:resourceType oslc:AutomationPlan. ]; # Note: OSLC Automation doesn't require creation of plans oslc:creationFactory [ oslc:creation </autoRequests/>; oslc:resourceType oslc:AutomationRequest. ]; oslc:creationFactory [ oslc:creation </autoResults/>; oslc:resourceType oslc:AutomationResult. ]. # Note: OSLC Automation doesn't require creation of results GET /autoPlans/ HTTP/1.1 Host: example.com 200 OK Content-Type: text/turtle Link: http://www.w3.org/ns/ldp#BasicContainer; rel="type", <http://www.w3.org/ns/ldp#Resource>; rel="type" @prefix dcterms: <http://purl.org/dc/terms/>. @prefix ldp: <http://www.w3.org/ns/ldp#>. <> a ldp:BasicContainer; dcterms:title "Tasks available for execution"; ldp:contains </autoPlans/1>, </autoPlans/2>, </autoPlans/3>. If we wanted to make the Service an LDPC itself (this time considering the case where the server doesn't support creation of Plans or Results): GET /automation/ HTTP/1.1 Host: example.com 200 OK Content-Type: text/turtle @prefix dcterms: <http://purl.org/dc/terms/>. @prefix oslc: <...>. Link: http://www.w3.org/ns/ldp#BasicContainer; rel="type", <http://www.w3.org/ns/ldp#Resource>; rel="type" <> a oslc:Service, ldp:BasicContainer; oslc:domain <http://open-services.net/ns/auto#>; dcterms:title "Task automation"; oslc:creationFactory [ oslc:creation ; oslc:resourceType oslc:AutomationPlan. ]; # Note: OSLC Automation doesn't require creation of plans oslc:creationFactory [ oslc:creation </autoRequests/>; oslc:resourceType oslc:AutomationRequest. ]; ldp:contains </autoPlans/>, </autoRequests/>, </autoResults/>. # Useful for querying, discovering dialogs, etc, etc. Martin Pain Software Developer - Green Hat Rational Test Virtualization Server, Rational Test Control Panel E-mail: Find me on: and within IBM on: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Next in thread →
Next in month →