[oslc-core] Oslc-Core Digest, Vol 13, Issue 3
Martin Nally
nally at us.ibm.com
Thu Feb 3 15:31:11 EST 2011
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: oslc-core-request at open-services.net
To: oslc-core at open-services.net
Date: 02/03/2011 02:02 PM
Subject: Oslc-Core Digest, Vol 13, Issue 3
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
(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 <ncrossley at us.ibm.com>
To: oslc-core at open-services.net
Subject: Re: [oslc-core] Core WG topic: Attachments and non-RDF
resources
Message-ID:
<OFCE013068.3F4C73B3-ON8825782C.006519C5-8825782C.00669259 at 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 at IBMUS
To: Dave <snoopdave at gmail.com>
Cc: oslc-core <oslc-core at open-services.net>,
oslc-core-bounces at open-services.net
Date: 02/03/2011 06:23 AM
Subject: Re: [oslc-core] Core WG topic: Attachments and non-RDF
resources
Sent by: oslc-core-bounces at open-services.net
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
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 <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
_______________________________________________
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/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 <nally at us.ibm.com>
To: oslc-core at open-services.net
Cc: oslc-core at open-services.net, oslc-core-bounces at open-services.net
Subject: Re: [oslc-core] Oslc-Core Digest, Vol 13, Issue 2
Message-ID:
<OF5D54C9BE.A4C1AC50-ON8525782C.005E25AA-8525782C.00680828 at 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: 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
>
------------------------------
_______________________________________________
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 3
****************************************
More information about the Oslc-Core
mailing list