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: [email protected] To: [email protected] Date: 02/03/2011 12:01 PM Subject: Oslc-Core Digest, Vol 13, Issue 2 Sent by: [email protected] Send Oslc-Core mailing list submissions to [email protected] 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 [email protected] You can reach the person managing the list at [email protected] 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 <[email protected]> To: oslc-core <[email protected]> Subject: Re: [oslc-core] Core WG topic: Attachments and non-RDF resources Message-ID: <[email protected]> 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 <[email protected]> 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 <[email protected]> To: Dave <[email protected]> Cc: oslc-core <[email protected]>, [email protected] Subject: Re: [oslc-core] Core WG topic: Attachments and non-RDF resources Message-ID: <of24833809.d047a894-on8525782c.004d3654-8525782c.004d7...@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 [email protected] Rational Software, IBM Software Group From: Dave <[email protected]> To: oslc-core <[email protected]> Date: 02/03/2011 08:19 AM Subject: Re: [oslc-core] Core WG topic: Attachments and non-RDF resources Sent by: [email protected] 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 <[email protected]> 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 [email protected] 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 [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net End of Oslc-Core Digest, Vol 13, Issue 2 ****************************************
