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 <[email protected]> > > 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 [email protected]
