Changes to valueType and representation shape properties (was: Dialog discovery: triple and Link header for discovery of dialogs won't be on same resources)

[Martin P Pain <martinpain@uk.ibm.com>]

(Bold text is to help scanning the
email).

I agree that we should re-introduce
olsc:representation into v3.

I am pretty sure that valueType is never
the same as range - it is either saying that the value should be a resource,
or stating the data type (e.g. xsd:date) of the literal value. (I don't
think data types can be used in range properties - I'm not entirely sure.
Range in RDFS allows clients to infer the rdf:type of resources that are
objects of a triple - and as OSLC avoids inference Steve Speicher always
suggested avoiding use of that kind of range - but I've never been sure
of the OSLC tables' "range" column is the same).

I also agree that, if we were starting
from scratch, then we should only have one valueType for RDF resources
(that is, oslc:Resource, which would actually be equivalent to v2's oslc:AnyResource).

(Such a change makes the shapes less
expressive. For example, while shapes can require that the resources be
inline, they cannot require that they be blank nodes [or hash URIs relative
to the request URI]. However, the reason that I would have supported just
having the one valueType for resources is that I believe such restriction
[requiring blank nodes] does not make sense. Specifically, as far as I
understand it, having a blank node in an RDF document does not state that
that resource does not have a URI, but rather makes no assertion about
its URI at all - please correct me if I am wrong. Requiring a lack of an
assertion is not extensible. I agree with Jim's assessment that what is
important to a client is whether they expect [or have to provide, when
POSTing] the representation of that resource inline or not. Similarly,
it makes sense for oslc:Reference to require the server to give the resource
a URI that can be requested [I'm not sure if that implies that it cannot
be a hash URI or not, but it certainly can't be a blank node], but I don't
see any sense in requiring the server to NOT give it such a URI - as long
as it's inline when it needs to be, I don't see why clients would care
what sort of URI (or not) it has.)

However, I'm not sure we can make
this change in a backwards-compatible way or not.

Train of thought:

1. We still need something to say that the value of a property is to be a resource (as opposed to a literal - even if technically they are resources we don't tend to treat them as such). So it would make sense to keep oslc:AnyResource (as that has the semantics that we want to keep) and deprecate oslc:Resource and oslc:LocalResource.
2. There isn't a problem in changing the shape documents to reflect this, as no v2 clients will be relying on them as we didn't publish any at v2.
3. Any references in the spec to oslc:LocalResource would become oslc:AnyResource with an oslc:representation of oslc:Inline.
4. That changes the semantics somewhat, so if there are any clients who will only work with blank nodes for those resources (or blank nodes plus local hash URIs), they will no longer work with v3 servers who decide to give those inline resources their own non-hash URIs. However, I hope that doesn't affect many clients. If using an RDF library to access the data, I hope they just ignore whether the resource has a URI or not, and just get the triples about it from the graph parsed from the representation. If using RDF/XML and parsing it with XPath (which is rather hacky) they couldn't rely on blank nodes being child elements of the resources that are lining to them anyway due to rdf:ID, so this doesn't change anything (they can still be child elements, and they can still be represented as separate elements elsewhere in the document).
5. Any references in the spec to oslc:Resource become oslc;AnyResource with an oslc:representation of oslc:Reference
6. I don't think this changes any semantics
7. If there were any uses of oslc:Resource that had an oslc:representation other than oslc:Reference then I believe that is an error, and it probably should have been oslc:AnyResource with that oslc:representation value anyway.
8. We're not adding any new semantics, so nothing to consider there.
   

I think we would need to test a selection
of v2 clients against servers that don't adhere to the oslc:LocalResource
"blank node" restriction.

However, just having read your email again
I'm not sure if you were suggesting changing the existing shapes/tables,
or just deprecating those valueType values and leaving them in the tables
that already use them. Less work for us, but the spec is less clear then.

Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel

E-mail: martinpain@uk.ibm.com 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"
<jamsden@us.ibm.com>
To:      
 OASIS <oslc-core@lists.oasis-open.org>
Date:      
 02/09/2015 22:12
Subject:    
   Re: [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>

---

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

E-mail:martinpain@uk.ibm.com 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