[oslc-core] Oslc-Core Digest, Vol 13, Issue 2
Martin Nally
nally at us.ibm.com
Thu Feb 3 13:56:18 EST 2011
I'm not sure how to give feedback on the wiki page except by responding to
this e-mail.
I have a couple of technical comments on your wiki page, explained below.
More generally I'm not sure of the value of the page. I could summarize the
page by saying "Attachment is not a special concept - the concept of
attachment is expressed in OSLC by a simple predicate that links two
resources. To express the fact that a resource has an attachment, create an
RDF triple whose object is the attachment, the subject is the resource to
which it is being attached, and the predicate is <not specified>". I agree
with that approach to attachment, but we don't need a web page to say this
- it can be said in a few words.
What I think is really the issue that people worry about is how to deal
with binary resources. In fact, this has nothing do do with attachments -
it just happens that the first time that people think about how to handle
binary resources is often when they are thinking about how to implement
attachments. "Binary resources" is a shorthand for "those resources whose
state cannot be entirely represented as RDF triples". Binary resources will
in fact have RDF properties, like dc:creator, dc:modified, but not all
their state can be represented this way. Your wiki page does not really
address the issues of binary resources directly, but one of your sequence
diagrams hints at your thinking.
(Embedded image moved to file: pic13931.jpg)
OslcCoreAttachments__Main__TWiki.jpg
WebSequence Diagrams notation for this interaction:
Consumer->Resource: GET
note left of Consumer: picks Attachment URI
Consumer->Attachment: GET on Attachment URI
Attachment->Consumer: sends back Attachment
note left of Consumer: edits Attachment image
Consumer->Attachment: PUT new image
Consumer->Resource: PUT with updated properties about Attachment
What you are doing here is to store the binary state of the image with the
image and store the RDF properties of the image with a different resource -
in this case the subject of the attachment. You can do this, but in my view
it's not a very attractive design, because it makes the handling of the
image very different from the handling of any other resource, and quite
complex. If I have the URL of the image, how do I know how to find the
resource that has the RDF properties of the image? What if the image is an
attachment of two different resources - do they both have the RDF
properties of the resource? What if it's not an attachment, it's an
appendage? We could probably write a more complex spec that answered these
questions, but I think that it is unnecessary to add this sort of
complexity. An alternative is the following, as I've described to you
before:
(Embedded image moved to file: pic17850.jpg)
Consumer->Resource: GET
note left of Consumer: picks Attachment URI
Consumer->Attachment: GET on Attachment URI
Attachment->Consumer: sends back Attachment
note left of Consumer: edits Attachment image
Consumer->Attachment: PUT new image (content-type:
application/octet-stream)
Consumer->Attachment: PUT with updated properties (content-type:
application/rdf+xml)
The obvious objection to this is that in the obvious interpretation of PUT,
the second PUT would erase the first, which is not what we want. The HTTP
spec description of the semantics of PUT is surprisingly crude, failing to
differentiate between representation and state
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6). What I
think it should have said is that the state of the resource should be set
from the new representation in the request - any old state that is not
derivable from the new representation would be discarded. One option would
be to assume that when you POST an RDF representation you should discard
the binary state - which never could have been expressed in the RDF
representation - but that would essentially disallow PUT on any resource
whose complete state cannot be represented in a single media type format
like RDF+XML. I chose to take a more flexible interpretation of PUT that
says that a PUT of an RDF representation will wipe out any previous RDF
state, but will not wipe out binary state, which can't be represented in
RDF anyway. You only erase the old state whose representation was
deliberately omitted from the new representation - the binary state was not
omitted, it's impossible to include it in an RDF representation. The
converse is true when setting binary state. This slightly more liberal
interpretation of PUT - which I claim is consistent with the spirit of HTTP
- avoids the complexity of the design your sequence diagram implies.
If you don't like my stretching of the definition of PUT, an even better
solution is to avoid PUT altogether and only use PATCH. This is actually a
better design anyway for OSLC - PUT of RDF is a bad idea because it assumes
that every client knows ALL the predicates that could and should be set on
a resource, not just the subset the client was coded to understand at a
point in time. There is a good reason that relational databases have no
equivalent of PUT - relational UPDATE is the logical analog of PATCH.
Best regards, Martin
Martin Nally, IBM Fellow
CTO and VP, IBM Rational
tel: +1 (714)472-2690
From: oslc-core-request at open-services.net
To: oslc-core at open-services.net
Date: 02/03/2011 12:01 PM
Subject: Oslc-Core Digest, Vol 13, Issue 2
Sent by: oslc-core-bounces at open-services.net
Send Oslc-Core mailing list submissions to
oslc-core at open-services.net
To subscribe or unsubscribe via the World Wide Web, visit
http://open-services.net/mailman/listinfo/oslc-core_open-services.net
or, via email, send a message with subject or body 'help' to
oslc-core-request at open-services.net
You can reach the person managing the list at
oslc-core-owner at open-services.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Oslc-Core digest..."
Today's Topics:
1. Re: Core WG topic: Attachments and non-RDF resources (Dave)
2. Re: Core WG topic: Attachments and non-RDF resources
(James Conallen)
----------------------------------------------------------------------
Message: 1
Date: Thu, 3 Feb 2011 08:16:56 -0500
From: Dave <snoopdave at gmail.com>
To: oslc-core <oslc-core at open-services.net>
Subject: Re: [oslc-core] Core WG topic: Attachments and non-RDF
resources
Message-ID:
<AANLkTik-e6FvqNV8ewRxOYCiZ8-Oq7SNzpJF5_eWXWb7 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
We had a good discussion of the topics of Attachments and Non-RDF
Resources. I think that some were confused because I was conflating
the two topics and covered many approaches, including an overly
complex one, but I think it was useful to discuss both topics
together.
To follow up, I have written a page that focuses on Attachments only.
Here's what I believe are the three important use cases for
attachments and a simple pattern for each:
http://open-services.net/bin/view/Main/OslcCoreAttachments
I think we want all domains to handle attachments in a consistent way,
so perhaps we should work to create a guidance document? Other ideas?
As always, feedback is most welcome.
Thanks,
- Dave
On Tue, Feb 1, 2011 at 4:17 PM, Dave <snoopdave at gmail.com> wrote:
> At the Core WG meeting tomorrow, we'll be discussing how to handle
> Attachments and non-RDF Resources.
> ? http://open-services.net/bin/view/Main/OslcCoreMeeting20110202
>
> I'll be using this presentation to explore various approaches:
> ?
http://open-services.net/pub/Main/OslcCoreMeeting20110202/attachments.pdf
>
> Whether you can attend the meeting or not your feedback is most welcome.
>
> Thanks,
> Dave
>
------------------------------
Message: 2
Date: Thu, 3 Feb 2011 09:05:49 -0500
From: James Conallen <jconallen at us.ibm.com>
To: Dave <snoopdave at gmail.com>
Cc: oslc-core <oslc-core at open-services.net>,
oslc-core-bounces at open-services.net
Subject: Re: [oslc-core] Core WG topic: Attachments and non-RDF
resources
Message-ID:
<OF24833809.D047A894-ON8525782C.004D3654-8525782C.004D7020 at us.ibm.com>
Content-Type: text/plain; charset="iso-8859-1"
I think there are a couple of points related to attachment lifecycle that
Nick had mentioned that are critical to the definition of an attachment
that could be added to this document.
1. Attachments are deleted when the referencing resource is deleted.
Attachments can be explicitly deleted without deleting the referencing
resource.
2. Attachments should (must?) be owned an managed by the same provider that
manages the resource that references it.
<jim/>
jim conallen
CAM Lead Architect, OSLC AM Lead
jconallen at us.ibm.com
Rational Software, IBM Software Group
From: Dave <snoopdave at gmail.com>
To: oslc-core <oslc-core at open-services.net>
Date: 02/03/2011 08:19 AM
Subject: Re: [oslc-core] Core WG topic: Attachments and non-RDF
resources
Sent by: oslc-core-bounces at open-services.net
We had a good discussion of the topics of Attachments and Non-RDF
Resources. I think that some were confused because I was conflating
the two topics and covered many approaches, including an overly
complex one, but I think it was useful to discuss both topics
together.
To follow up, I have written a page that focuses on Attachments only.
Here's what I believe are the three important use cases for
attachments and a simple pattern for each:
http://open-services.net/bin/view/Main/OslcCoreAttachments
I think we want all domains to handle attachments in a consistent way,
so perhaps we should work to create a guidance document? Other ideas?
As always, feedback is most welcome.
Thanks,
- Dave
On Tue, Feb 1, 2011 at 4:17 PM, Dave <snoopdave at gmail.com> wrote:
> At the Core WG meeting tomorrow, we'll be discussing how to handle
> Attachments and non-RDF Resources.
> ? http://open-services.net/bin/view/Main/OslcCoreMeeting20110202
>
> I'll be using this presentation to explore various approaches:
>
http://open-services.net/pub/Main/OslcCoreMeeting20110202/attachments.pdf
>
> Whether you can attend the meeting or not your feedback is most welcome.
>
> Thanks,
> Dave
>
_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110203/b4cc840b/attachment-0001.html
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <
http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110203/b4cc840b/attachment-0001.gif
>
------------------------------
_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net
End of Oslc-Core Digest, Vol 13, Issue 2
****************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic13931.jpg
Type: image/jpeg
Size: 27403 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110203/e242ec38/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic17850.jpg
Type: image/jpeg
Size: 43439 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110203/e242ec38/attachment-0001.jpg>
More information about the Oslc-Core
mailing list