[Oslc-Automation] Templates: Submitting as blank nodes?
Martin P Pain
martinpain at uk.ibm.com
Tue Jan 7 06:29:05 EST 2014
So you were thinking of templates being operated on at a document level,
not a resource level? i.e. the consumers do not parse the contents of the
response to the GET on the template URI, merely store it? i.e. it is
opaque. I wasn't thinking along those lines, but I'm happy to accept that.
(1) We need to state that.
(2) For consumers that are using some generic RDF interface/libraries,
rather than performing the GETs themselves, they would need to treat the
template URI differently than standard RDF resource URIs. As it shouldn't
be their RDF library that looks up the template (as it would parse it, and
possibly loose the document boundaries, lose the media type, etc), rather
the consumer code needs to get the URI out and perform its own GET in
order to store the contents opaquely as a blob.
(3) In the case of Actions, how do we say "this URI is for a template -
don't parse it" separately from "this URI points to a remote resource, GET
it, parse it, and do whatever's needed based on its type". This is why I
think we need the indirection, although perhaps
ContentAsBase64/ContentAsText would be enough, and we might not need the
proposed RDF case. (This would also not hit the problem where http:body
defines its range as ContentAsBase64, which means any object of that
predicate could be inferred to have rdf:type content:ContentAsBase64.)
However I don't think they could refer to a remote resource, I think the
bytes/text would have to be inline, which is not what we want. The content
spec uses the dcterms:isFormatOf predicate to point to the URI that the
bytes were retrieved from, so perhaps we could use:
<action>
http:body [
rdf:type content:Content; # If we're specifying neither bytes nor
text,
# then I guess we don't need a sub type
dcterms:isFormatOf <...>; # URI to template document
]
#...
.
But this doesn't feel right.
Kind regards,
Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel
Open Services for Lifecycle Collaboration - Automation WG joint chair
E-mail: martinpain at 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: John Arwe <johnarwe at us.ibm.com>
To: oslc-automation at open-services.net,
Date: 06/01/2014 17:36
Subject: Re: [Oslc-Automation] Templates: Submitting as blank
nodes?
Sent by: "Oslc-Automation"
<oslc-automation-bounces at open-services.net>
> The new template dialog section [1] of the spec does not include any
> instructions on what to do with such a template.
>
> I know (or at least think I know) from the previous discussions that
> the intention is to submit it to a creation factory.
> Firstly, this is not stated. (Admittedly, consumers can do anything
> they like with it when they have it, so we don't want to restrict
> this, but perhaps we should express our intention. Perhaps a link to
> the scenario page?)
Agree we should say something explicit.
Link to scenario flow too. Since scenarios are not normative, need more.
IIRC we have link(s) FROM each Action-template-dialog TO 1:*
Creation-dialogs known to be capable of consuming the template dialog's
output resource... and that should be MUST be capable of consuming, since
that's what's needed for interop.
> Secondly, this template will be a resource with a specific URI. When
> you submit it to the creation factory, if you do no processing of
> the resource you will be submitting it with that template URI. The
> Core spec on creation factories [2] doesn't state whether the RDF
> being POSTed to it should be a blank node or have a URI - and if the
> latter, what it does with that URI.
I would simply make the requirement that the template-dialog-output
resource's representation MUST be consumable as input to a standard
creation factory (which already has all the same problems). The provider
has to forge the linkage, as the simplest thing that can work. Do we have
any scenarios that require the two dialogs be provided by separate
providers? If so, we'd have to specify more probably.
> I guess, as it currently stands, it would be up to the
> implementation to either replace the URI in the representation
> POSTed to the factory,
I.e. act as a standard creation factory. The question of how to interpret
input subject URIs is underspecified today, although LDP addresses it for
the case we normally consider (null relative URI, "<>" in Turtle terms).
Or if you prefer, today it devolves to HTTP POST's allowance to use any
request-body as "instructions" for what to do, which is underspecified
with respect to create if you demand interop based purely on the HTTP spec
contents.
> or to create the new AutoRequest at the same
> URI (although this might cause problems if submitted more than once).
Actually I don't think Create (201 response) is an issue; "create at the
same URI" is a technical worst (violation of best) practice in WebArch. If
the server replies 201, the client expects that a resource unique in time
and space has been newly created. Since it's unique, it has a new URI.
Automation's various permitted patterns however already assign a meaning
to a 200 response, so things could be confusing. We should specifically
say I think that *if* the implementation uses the 2.0 200-response
pattern, then... something (I'd have to refresh myself on the 2.0 base to
be more precise). IIRC in that case the response has no
guaranteed-retrievable URI for the resource. I'm confident there's enough
wiggle room in the spec stack to Allow this to work, less so that there's
any strong guarantee w/o new words.
> We also use the template concept in Actions, in the "HTTP request
> with RDF body" interaction pattern [3].
>
> In both these cases - both with template dialogs and Actions - it's
> possible that implementations might want to specify whether the
> template should be POSTed with the subject URIs intact, or whether
> it should be copied to a blank node (as it's a new resource that
> will be created, at a factory-assigned URI).
The whole point of the template pattern is to keep the representations
opaque. Maybe we need to say that, describe all actors' responsibilities
*in that case*, and then stop; explicitly say that once you break that
opacity, it's up to you to figure out all the corner cases that will
arise.
> With Actions, if we go down the route of defining a ContentAsRDF
> class, then this would be possible as the provider could set the
> value of the (proposed) oslc:resource either to be a link to a URI
> to be dereferenced (if the template is to be submitted with-URI) or
> as a blank node (if it is to be submitted as a blank node).
Could, yes. Need to now (in order to make existing scenarios work), I
don't think so. I have not seen anyone pleading for the input-link form.
If we see a way to extend things later to support that *should it become
needed*, then I don't see any need to specify it now. If we don't see
such a way, we probably have a larger problem.
Devil's Advocate: I'm not sure I see the need for ContentAsRDF yet (or
maybe I forgot it; if so, sorry). Assuming opaque representations
(again), all the client needs to do is GET it from the template dialog's
result, stash "what's needed" (content + Content-Type header, at least),
and feed that in to a creation factory *specified by the template dialog's
provider* later.
Best Regards, John
Voice US 845-435-9470 BluePages
Tivoli OSLC Lead - Show me the Scenario
_______________________________________________
Oslc-Automation mailing list
Oslc-Automation at open-services.net
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
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 part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140107/5a6f7fee/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 518 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140107/5a6f7fee/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1208 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140107/5a6f7fee/attachment-0001.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140107/5a6f7fee/attachment.gif>
More information about the Oslc-Automation
mailing list