oslc-core message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [oslc-core] Discovery scenarios (LDPCs)
- From: Martin P Pain <martinpain@uk.ibm.com>
- To: "Jim Amsden" <jamsden@us.ibm.com>
- Date: Thu, 10 Sep 2015 09:57:01 +0100
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 |
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 |
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"
<jamsden@us.ibm.com>
To:
OASIS <oslc-core@lists.oasis-open.org>
Date:
03/09/2015 14:48
Subject:
Re: [oslc-core]
Discovery scenarios (LDPCs)
Sent by:
<oslc-core@lists.oasis-open.org>
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 <martinpain@uk.ibm.com>
To: Jim
Amsden/Raleigh/IBM@IBMUS
Cc: OASIS
<oslc-core@lists.oasis-open.org>
Date: 09/03/2015
09:11 AM
Subject: Re:
[oslc-core] Discovery scenarios (LDPCs)
Sent by: <oslc-core@lists.oasis-open.org>
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 |
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" <jamsden@us.ibm.com>
To: OASIS
<oslc-core@lists.oasis-open.org>
Date: 03/09/2015
03:01
Subject: Re:
[oslc-core] Discovery scenarios (LDPCs)
Sent by: <oslc-core@lists.oasis-open.org>
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 <martinpain@uk.ibm.com>
To: Martin
P Pain <martinpain@uk.ibm.com>
Cc: OASIS
<oslc-core@lists.oasis-open.org>
Date: 09/02/2015
09:19 AM
Subject: Re:
[oslc-core] Discovery scenarios (LDPCs)
Sent by: <oslc-core@lists.oasis-open.org>
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 |
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
<oslc-core@lists.oasis-open.org>
Date: 28/08/2015
17:03
Subject: [oslc-core]
Discovery scenarios (LDPCs)
Sent by: <oslc-core@lists.oasis-open.org>
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 |
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
and
within IBM on: 
and
within IBM on: 
and
within IBM on: 
and
within IBM on: 
and
within IBM on: 
