Martin's description of our use case is accurate - and yes, it is certainly applicable to more than just attachments. I think this use case is important because some systems will not allow you to create a free-floating dependent resource or sub-web and then link it to its parent later - an unattached 'attachment' might be a violation of referential integrity, or simply not possible in some tools. If you can use simple linked data, as per the description in Dave's current scenario #1, then I absolutely agree that should be used, and I agree that we do not need a separate guidance page to describe it. I do believe we should have a recommended approach to the more complex case.
Nick. From: Martin Nally/Raleigh/IBM@IBMUS To: [email protected] Cc: [email protected], [email protected] Date: 02/03/2011 12:35 PM Subject: Re: [oslc-core] Oslc-Core Digest, Vol 13, Issue 3 Sent by: [email protected] The model that Nick and Jim are describing seems to be the ability to create a "sub-web" of resources with a single "root resource" where the life-cycle of the sub-web is linked to the life-cycle of the root. In this case the "root" of the sub-web is an arbitrary resource, and the subordinate elements of the "sub-web" are its attachments, but you can imagine other scenarios fitting this pattern. The characteristics of the sub-web seem to be: Sub-elements are created by POSTing to a factory specific to the root resource of the sub-web (could be the root itself). Resources created by other means cannot be subsequently "linked in" to the sub-web, and resources created as subordinate elements cannot be subsequently "un-linked" from the sub-web, so even though membership of the sub-web is represented by a predicate, you can't manipulate the predicate directly in the normal way. If the root is deleted, the whole sub-web is deleted One obvious question is why we think this pattern is important enough for us to specify. I know attachments have traditionally worked this way, but it's not clear to me if that is because it was required by user scenarios, or just that it was easy for systems like email and forums to implement this pattern in the absence of a more general linked data capability. I suspect the latter, but I'm not sure. I interpreted Dave's wiki page as saying "lets not worry about reproducing historical attachment models exactly - lets just use linked data in the natural way to create and link resources". I rather like that view, at least as an opening negotiating position. If I'm wrong and we really do need to specify this "sub-web" pattern, let's do it a bit more generally that just for attachments. 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 02:02 PM Subject: Oslc-Core Digest, Vol 13, Issue 3 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 (Nick Crossley) 2. Re: Oslc-Core Digest, Vol 13, Issue 2 (Martin Nally) ---------------------------------------------------------------------- Message: 1 Date: Thu, 3 Feb 2011 10:40:21 -0800 From: Nick Crossley <[email protected]> To: [email protected] Subject: Re: [oslc-core] Core WG topic: Attachments and non-RDF resources Message-ID: <ofce013068.3f4c73b3-on8825782c.006519c5-8825782c.00669...@us.ibm.com> Content-Type: text/plain; charset="us-ascii" I agree with Jim's comments, and I was surprised to see no mention of the attachment factory left in the revised discussion. If a service does not permit free-standing attachment resources, but insists they be related to the parent resource, then use case #1 needs a slightly different approach: The consumer knows the appropriate URI for an attachment factory (perhaps from the service description), or gets that URI form the parent resource The consumer POSTs the attachment to the attachment factory - the attachment factory URI is specific to the parent resource, or is passed the parent resource URI as a query string The attachment factory creates the attachment resource, creates the link from the parent to the attachment*, and returns the URI of the new attachment The consumer adds any additional properties it desires for the attachment itself, or for the link between the parent and the attachment * In the meeting, someone brought up the question of whether the link should really go from the parent to the attachment, or from the attachment to the parent. We did not discuss this in detail, and the wiki page suggests only the former. Nick. From: James Conallen/Philadelphia/IBM@IBMUS To: Dave <[email protected]> Cc: oslc-core <[email protected]>, [email protected] Date: 02/03/2011 06:23 AM Subject: Re: [oslc-core] Core WG topic: Attachments and non-RDF resources Sent by: [email protected] 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 Dave ---02/03/2011 08:19:05 AM---We had a good discussion of the topics of Attachments and Non-RDF Resources. I think that some were 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 _______________________________________________ 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/3707c7ce/attachment-0001.html > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 105 bytes Desc: not available URL: < http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110203/3707c7ce/attachment-0001.gif > ------------------------------ Message: 2 Date: Thu, 3 Feb 2011 13:56:18 -0500 From: Martin Nally <[email protected]> To: [email protected] Cc: [email protected], [email protected] Subject: Re: [oslc-core] Oslc-Core Digest, Vol 13, Issue 2 Message-ID: <of5d54c9be.a4c1ac50-on8525782c.005e25aa-8525782c.00680...@us.ibm.com> Content-Type: text/plain; charset="us-ascii" 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 **************************************** -------------- 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 > ------------------------------ _______________________________________________ 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 3 **************************************** _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
