[oslc-cm] A Modest Proposal for Attachments

[Dave Steinberg]

Hi Steve,

Thanks very much for the positive feedback and the specific comments and
suggestions. Here are my thoughts on them.

Steve K Speicher/Raleigh/IBM wrote on 07/20/2011 07:51:58 AM:
>
> From: Dave Steinberg <davidms at ca.ibm.com>
> > I'm just using the standard RDF container membership properties here.
That
> > said, I know they're not popular in OSLC (though I don't really
understand why)
>
> I'm not really sure there is any true apposition to it.

Interesting. I thought the advice from Core was to use rdfs:member (which
I'm not a fan of, for conceptual and practical purposes) or define a
particular property in the domain spec. The main objection I have heard is
that writing queries against the membership properties requires inference,
which is true, though I understand ARQ provides special support to handle
that particular inference very efficiently and doesn't handle the actual
use of rdfs:member at all well.

> I'm not sure this is a true statement.  The triples have as an object the

> actual attachment they are describing.  You are requesting additional
> semantics of when you do a GET on the attachment collection resource that

> you must also return the triples about the attachments.  So this
indicates
> a special case of GET, which may be worth doing but wanted to indicate as

> such.  I'll suggest an alternative in a bit.

I agree that it's a special case in the context of OSLC, but I don't think
it's a particularly unusual use of RDF in general. Think of the basic
example of using RDF with DC Terms to provide metadata about Web pages.
Those statements may well not be on the pages themselves, but in a separate
catalog. Similarly, in this case, I'm suggesting putting additional
statements about the attachment resources in their "catalog", the
attachments list for a change request, for the convenience of the consumer.
I'm of the opinion that suggesting or requiring that a provider do this
isn't problematic, and a well-written client can easily deal with their
presence or absence.

> Let me suggest a slight modification to this concept and that is a what
to
> handle the attachment "metadata" independent of the attachment collection

> it belongs.
> Let's start again with your example:
>
> <http://example.com/bugs/2314/attachments>
>    rdf:type oslc_cm:AttachmentList ;
>    oslc_cm:attachment <
> http://example.com/bugs/2314/attachments/screenshot.png> ,
>    <http://example.com/bugs/2314/attachments/fix.patch> .
>
> Now let's say I want to retrieve the metadata about attachment
> screenshot.png.
> We could use some URL math to add on a request for metadata such as: GET
> http://example.com/bugs/2314/attachments/screenshot.png?metadata
> This has the nice quality of being a different URL than the attachment
> itself, therefore in RDF terms is a different resource.  It can be
> computed easily from the attachment.  You can PUT on that URL to just
> update the metadata and not require special request headers.  The
downside
> is if the server really doesn't understand ?metadata, you may get back
the
> attachment when you don't want it.
> Another alternative is HTTP content negotiation, you could request
Accept:
> text/turtle on the attachment URL and get just the metadata.  This has
the
> drawback of conflicting when your attachment IS text/turtle....maybe a
> rare case but still an issue.

I definitely think that using content negotiation isn't the right approach
for exactly the reason you give. Also, conceptually, I think it's not
correct: the metadata is not another representation of the resource, it's
an entirely different set of data.

I think the query approach is valid, but I still prefer my original
suggestion because I think the metadata is more useful to the consumer in
the same resource as the list of attachments. From my experience with
clients, I've noticed that list resources aren't generally much use without
at least some data about the members from which a label can be rendered.

Think about the Attachments UI in Bugzilla (e.g.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=1#a0). If a consumer wanted
to render something like that for a change request's attachments, it would
be very helpful to have all the metadata right in the attachment list.
Without that, there would be a lot of GETs involved.

Another consideration with the query approach is that, if the metadata URIs
aren't discoverable but need to be formed, then that's another concept for
producers and consumers to know about. If it's more generally applicable,
should it be defined in Core?

Assuming that we expect providers to include all of the metadata in HTTP
headers, as I had proposed, another alternative is simply to do a HEAD on
an attachment resource to get that information. One reason I had proposed
the header approach is that some or all of that data may be needed at
attachment creation time by some underlying systems, so creating the
attachment then specifying the metadata wouldn't work.

Talk to you tomorrow.

Cheers,
Dave

Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-cm_open-services.net/attachments/20110726/1d0bef41/attachment-0003.html>