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: Fri, 25 Sep 2015 11:01:18 -0400
Martin,
I may not sufficiently understand the
details of RDf and its representations - but I had thought the fragment
URIs in an RDF/XML representation were basically a convenience for the
notation, sort of like namespaces. That is, once the fragment is combined
with either the XML base or the resource URI, it becomes a URI. It carries
no other meaning.
It also seems inlining is orthogonal
to the URI representation in a resource representation. Clearly blank nodes
don't have referencable URIs outside the resource representation, and therefore
the content has to be inlined. But any other URI can refer to something
that is inlined or not - its just a representation of something that may
also be referencable in its own right.
My perhaps overly simplistic view of
this is that we need to be able to constrain or specify the type of an
object as either a literal or a URI to some RDFS/OWL class (or more generally,
a vocabulary element). And we need to be able to constrain a particular
representation of a particular class's properties to be inlined in order
to efficiently support certain use cases.
oslc:valueType constrains the types
for object literal values, but it specifies the URI representation in a
document for object references (oslc:AllowedValues constrains the type
for object references). I suppose that's a value type, but it feels strange
to me, and seems to overlap with oslc:representation, creating a number
of invalid combinations of the two properties as shown in Nick's table.
oslc:representation, applied to a property,
would seem to be sufficient to indicate whether values of that property
should be included inline or not for efficient access. I would think this
is something servers SHOULD, but are not required to do - there may be
many use cases that would need direct access to the object. Codifying efficiency
for specific use cases into a fixed schema might create problems for future
use of that information. Making oslc:Inline a MUST also encourages poor
use of RDF/XML including the use of XPath queries to access information
without parsing the RDF/XML.
Finally, it seems oslc:representation
should be a property of a property in the context of a specific resource
intended to be used for a specific purpose, not any representation of the
resource for potentially other, very different purposes. Now we're potentially
getting into a situation where some header or MIME type is required to
tell servers what that use case is so the server can provide an appropriate
resource representation. This feels like a dangerous place to go.
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575
From:
Martin P Pain <martinpain@uk.ibm.com>
To:
Arthur Ryman <arthur.ryman@gmail.com>
Cc:
Jim Amsden/Raleigh/IBM@IBMUS,
OASIS <oslc-core@lists.oasis-open.org>
Date:
09/25/2015 06:04 AM
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>
Hi Arthur,
Thanks for catching up with this & bringing in your experience with
its origins.
In my reply to Jim's email that you replied to below: https://lists.oasis-open.org/archives/oslc-core/201509/msg00031.html
I said: - "I agree that we should re-introduce
olsc:representation into v3. " - I'm sure you will agree with this.
- "I am pretty sure that valueType
is never the same as range" - I' confident that you will agree with
this.
- "I also agree that, if we were
starting from scratch, then we should only have one valueType for RDF resources"
- I expect you would disagree with this. I think it would be useful to
have some scenarios/examples (covering at least GET and POST cases, probably
PUT as well) showing in what cases requiring or prohibiting blank nodes
would be useful (and when requiring or prohibiting inlining would be useful)
to show the value of having these three valueTypes for resources.
- "Any references in the spec to
oslc:LocalResource would become oslc:AnyResource with an oslc:representation
of oslc:Inline." - even if we don't deprecate any of the resource
valueTypes, it feels like when talking about GETs (which the vast majority
of the shapes in the spec do.... I think.... at least that's how I read
them) there's no need to force something to be a blank node - as long as
it is inlined when it should be, as far as I can see that's what matters
to a client doing a GET. When POSTing I can understand that a server doesn't
want the client to force certain IRIs in the body, so requiring blank nodes
might make more sense. This suggests to me that perhaps we ought to have
separate shapes for POSTing and getting...not that we have the time to
make those sort of changes. This is very much getting into the scenarios
discussion that I suggest above - showing what the value & motivations
are for requiring or prohibiting blank nodes, and also looking at the difference
between GETs and POSTs.
- (Aside: you said in issue 34 that "
In RDF, IRI are opaque identifiers so you really should not talk about
fragments since it's not meaningful from an RDF viewpoint." - however,
when POSTing, especially to create a resource, it seems that there is a
distinction. It seems to me that it should be perfectly valid and acceptable
for a representation being POSTed in a creation request to define its own
relative fragment identifiers [e.g. <#me> - with no base IRI defined],
which will be resolved relative to the IRI the server mints for the new
resource [if the server allows relative graphs]. However if the representation
contains triples whose subject is another resource entirely, specifying
its absolute IRI on the same server, then that is ambiguous as to whether
it wants the server to create that resource or just store triples about
it in this resource's graph/representation - it depends what sort of model
the server is using, and I expect most implementations would want ot avoid
that sort of thing. I'm not sure I made myself clear here, but what I wastrying
to say is that in GETs I can see that IRIs are opaque, whether they contain
fragment identifiers or not, but that in POSTs there is a difference between
an IRI to another resource and relative fragment identifiers.)
I withdraw my suggestion from that email to deprecate oslc:Resource and
oslc:LocalResource. However I'd like to see examples (which hopefully already
exist) of when requiring or prohibiting blank nodes is useful, so we can
be confident of what should be in the shapes in the spec.
Thanks,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: Arthur
Ryman <arthur.ryman@gmail.com>
To: Jim
Amsden <jamsden@us.ibm.com>
Cc: OASIS
<oslc-core@lists.oasis-open.org>
Date: 24/09/2015
23:14
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>
Jim,
Still catching up after vacation. Your comments contain some misinterpretations.
I've replied in other several places. Is this still an issue. fyi, I tried
to clarify the meaning of these vocabulary terms in the W3C submission.
Please refer to http://www.w3.org/Submission/2014/SUBM-shapes-20140211/#valueType.
-- Arthur
On Wed, Sep 2, 2015 at 5:12 PM, Jim Amsden <jamsden@us.ibm.com>
wrote:
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
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]