On Fri, 2009-11-06 at 16:21 +0100, Chris Wilper wrote: > Hi Asger, > > On Fri, Nov 6, 2009 at 5:48 AM, Asger Askov Blekinge > <[email protected]> wrote: > > [..] > > Then, for datastreams with special content, where we would like to > > modify the contents in a language appropriate to this content, we would > > use disseminators. > > Yes, this is what we talked about in the call, and what the current > strawman presents. I like to explain people's ideas back to them, to be sure we understand them the same way ;)
> > > We could, and should make default disseminators, that could provide the > > object as a RDF graph in alternative serializations. These are not > > difficult to make, the code just needs to be done. > > Should it be all the per-object triples that go into the RI? That is, > the union of (RELS-EXT, RELS-INT, inferred triples from DC, inferred > triples from the FOXML). That would be my opinion, yes. > > > But more importantly, we should have POSTable disseminators. POSTable is > > very much not the same as writable. POST is the http equivalent of > > "invoke" or "call", i.e. the URL POSTed is the location of the method to > > invoke. This is different from PUT which understands the URL as the > > location to put the content to. > > Good description. Thanks. > > > I fail to see how allowing POSTable disseminators will be a big change > > to Fedora, but then I do not entirely understand the disseminator > > structure. > > There is no argument about whether it should be done: > > https://fedora-commons.org/jira/browse/FCREPO-500 > > What we really need is for someone to focus in and make it happen. What I meant was that I could not see how it would be a lot of work to make it happen, not whether or not it should be done. > > However, whether that functionality exists for user-defined SDeps is a > separate issue from whether Fedora's core REST api is defined to use > it. As pointed out on the call, if FCREPO-500 doesn't exist, we can > always "fake the syntax" so it looks like it is, for the default > disseminator. And I support that decision. But after having looked at the code I believe faking it might be more difficult than doing it correctly. But anyway, that is for the people who are going to do it to decide, and they haven't been selected yet. > > > Perhaps we should find another name for disseminators, like > > Methods, as they will now do more than disseminate the object. > > Yes. Disseminator is a distinctive term, which, besides habit, is one > reason we keep falling back to using it when talking about this stuff. > But the terms "operation", "method", or even "endpoint" are more > amenable to what we want these to be. Methods is already used about them in Fedora. Services also, but that has slightly different meaning. I will use methods for now on. > > > By having POSTable disseminators, we can send content, that the > > disseminator must translate into the correct Fedora api calls, like > > modifyDatastream. Having a default disseminator that accepts > > SPARQL/update blobs and update the RELS-EXT and RELS-INT seems like a > > very good idea. > > > > Chris said "Yeah, as I was writing this up it just felt weird to have > > the partial mods going to an entirely different kind of URL than full > > adds/mods. " > > I disagree with that, and I believe I have the HTTP docs on my side. To > > me, it seems weird to have the datastream as both a resource and a > > invokable method. > > Here's the relevant bit of RFC2616 is Section 9.5: > > "The POST method is used to request that the origin server accept the > entity enclosed in the request as a new subordinate of the resource > identified by the Request-URI" > > Although we often ignore versioning for simplicity, the datastream URL > in the REST API can really be seen as identifying a collection of > datastream revisions. So POSTing to it seems like a REST-compatible > option to me. You ever so slightly changed the subject ;) I said I did not feel it was weird to POST the partial mods to a different URL than the one where the change is performed. POST is designed to allow for this ". POST is designed to allow a uniform method to cover the following functions: - Annotation of existing resources; - Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles; - Providing a block of data, such as the result of submitting a form, to a data-handling process; - Extending a database through an append operation. " Posting directly to the datastream would be REST compatible, btw. > > > What would be nice was to have disseminators directly on the > > datastreams, not on the object. > > Although it could be read as such, I assume you're *not* proposing to > get rid of the idea that disseminators can still act on the object as > a whole. Of course not. But every time we discuss these methods, we talk about them disseminating a particular datastream or updating a datastream. But that is not what they do at the moment, they work on the entire object. > > > I have an idea for how to do this. > > First, to invoke such a disseminator, you use > > GET/POST > > /objects/{pid}/datastreams/{dsID}/methodFrom/{sdefPid}/{methodname}?params > > This will make the idea of partial updates clearer, and at the same time > > allow us a standard format of disseminator for methods. > > Not sure I understand the utility of the string "methodFrom"...is that > just a delimiter indicating that a "datastream method" is being > invoked? I just like the delimiters to make a URL more readable. You should just ignore it. > > > Implementing it: In the current disseminator structure (Christ I have > > typing in disseminator by now...), disseminators are bound by a relation > > from a content model. We have two ways of doing this now: > > 1. Using RELS-INT to declare "contentmodels" for datastreams > > 2. Using an extension for DS-TYPE-MODEL. > > > > I like method number 2, and it should be fairly straightforward to imple > > ment. > > What other kinds of use cases would this help with? The problem at > hand is how to expose relationship-modifying methods as out-of-box, > REST-exposed functionality in Fedora. I see how having "datastream > methods" might make the syntax a bit more palatable than, say, passing > a dsID as a parameter to an object method. But that alone doesn't > seem like enough of a reason to define a new kind of disseminator. I can give you a lot of use cases, but they same invariant will be true in all of them: They can be done with an object method and a dsID parameter. Usecases: 1. Exposing an inline datastream as Json or other serialization ( or RDF as other kinds of tuples) 2. Converting a datastream to RDF for storing in the triple store (rather than using an XSLT) 3. Posting modifications rather than full content, in arbitrary languages 5. Doing odd stuff with updating the real contents of external datastreams. I see the atomic unit of Fedora as the datastream, not the object. The datastream is a mini-object, having relations, title, one blob of content and versioning. This was less clear before the introduction of RELS-INT. What datastreams lack to be full objects are: Methods A helpful API With a bit of magic the datastream even has a audit trail. Regards > > - Chris ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Fedora-commons-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
