oslc-core message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [oslc-core] Dialog discovery: triple and Link header for discovery of dialogs won't be on same resources
- From: "Jim Amsden" <jamsden@us.ibm.com>
- To: OASIS <oslc-core@lists.oasis-open.org>
- Date: Wed, 2 Sep 2015 17:12:32 -0400
I'm trying to understand the point of ResourceShape
valueType and representation properties.
oslc:valueType description is: "A
URI that indicates the value type, for example XML Schema or RDF URIs for
literal value types, and OSLC-specified for others. If this property
is omitted, then the value type is unconstrained." That is defining
the type of the property, not its representation in a resource, and covers
what would be captured in the RDFS/OWL range property of the property.
The description for property oslc:representation
is "Should be http://open-services.net/ns/core#Reference,
http://open-services.net/ns/core#Inlineor http://open-services.net/ns/core#Either".
This is addressing whether the representation of the referenced object
must or may be in the same resource representation as the subject of that
property. This is probably included in order to limit the number of GETs
required to do discovery. Its a resource representation optimization that
has no semantic meaning.
Later on in the ResourceShape vocabulary,
there is a comment: "<!-- ********** Property: oslc:valueType allowed
values ********** -->" which is followed by the enumeration types
for Resource, LocalResource and AnyResource. This seems completely orthogonal
to the definition of oslc:valueType and its common use to specify expected
type of the value of a property, and appears to overlap with the values
for oslc:representation.
In particular, oslc:valueType of LocalResource
could only have oslc:representation oslc:Inline, and all instances of oslc:representation
Inline in the OSLC2 specification have oslc:valueType LocalResource.
What seems to have happened is that
oslc:valueType got somewhat overloaded. If the valueType is a resource,
then it can have a representation. No other value type can have a representation.
A resource shape might specify multiple valueTypes for a property, one
that is the property's type (i.e., the object of its range property), the
other is a tag indicating how the property value (that is a resource) should
be represented in an HTTP resource - inlined (blank node or relative URI)
or as a (potentially) external GETtable resource in its own right.
But this overlaps with oslc:representation
which says the same thing. So I think valueTypes of Resource, LocalResource
or AnyResource are redundant and unnecessary (but can't be removed). The
value of a property should simply have a type, and if its type is
a non-primitive resource, then that value should have a representation
that MUST or MAY be in the same resource as the subject URI.
Given the description above, we should
be able to decouple resources from their particular representation. That
is, a ServiceProvider resource representation would expect its Service
instances to be inlined in that representation. But this shouldn't mean
the Service can't be an LDPC in its own right, and certainly a GET on a
Service URI would return a resource representation in which the Service
is inlined!.
So I don't think there's a problem here.
We should:
1. deprecate the use of oslc:Resource,
LocalResource and AnyResource since they are redundant with oslc:representation.
Any value of oslc:representation applies to any resource, so that doesn't
need to be stated. oslc:representation for a LocalResource has to be Inline.
Clients can't make any assumptions about the representation for AnyResource.
So again, all values of oslc:representation apply.
2. add oslc:representation back into
the OSLC3 specifications (it was removed and doesn't appear in any of the
shape .ttl files or generated tables)
3. Treat oslc:representation as a means
of specifying what should be included in resource representations that
reference properties, but does not constrain where servers actually manage
those resources. That is, the value of a property with oslc:representation
oslc:Inline could be a blank node, relative (or hash) URI, or a URI to
a resource that that can also be the URI of a GET request, even though
it would be accessed inline in any other referencing resource representation.
As a result, get on a ServiceProvider
would include the publisher and services inline, but each Service could
also be the URI of an LDPC in an OPTIONS, HEAD, or GET method that provides
Link headers for discovery.
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575
From:
Martin P Pain <martinpain@uk.ibm.com>
To:
OASIS <oslc-core@lists.oasis-open.org>
Date:
09/02/2015 10:14 AM
Subject:
[oslc-core]
Dialog discovery: triple and Link header for discovery of dialogs won't
be on same resources
Sent by:
<oslc-core@lists.oasis-open.org>
We have three mechanisms of discovering
dialogs:
Link headers & Prefer headers: http://tools.oasis-open.org/version-control/browse/wsvn/oslc-core/jra-editing/specs/dialogs.html#discovery_link
and oslc:selectionDialog/oslc:creationDislog triples in oslc:Service resources:
http://tools.oasis-open.org/version-control/browse/wsvn/oslc-core/jra-editing/specs/discovery.html#dialogs
I had previously expected that these headers and these triples would be
on the same resources, but they cannot be.
The triples are on oslc:Service resources, but OSLC
v2 requires that these resources
be "Local Resources", which it defines to mean blank nodes (although
I need to raise a separate issue to clarify whether the intention was to
allow for hash URIs or not). "Local Resources" cannot have headers
of their own, so oslc:Service resources cannot have Link header. (If they
have hash URIs, technically they can have their own Link headers, but I
don't suggest we go down that route.)
The Link and Prefer headers will be on LDPs themselves. (Although currently
I don't think we have a good way of finding those LDPCs).
Is everyone else ok with the fact that these headers and triples will be
on different resources? I just wanted to make sure we're clear what
the situation is and are ok with it.
(This might make more sense in the context of my previous email and the
wiki page it links to, where I'm thinking about how a server with one or
more LDP containers makes those containers and their capabilities discoverable
using OSLC).
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]