 |
 |
No, yes and no. No, I was hoping to co-opt recordSchema, as it has semantics close to what I want. Well, close as we get today. Having coined recordAccept, which says pretty much exactly what I want, then I suppose that would be best. Yes, you would list the media types that you want and can use the quality option to say what order you would prefer them in: application/marc21+xml;q=0.9, application/mods+xml;q=0.8 No, there is the concept of experimental media types that can be used between consenting adults. http://www.mhonarc.org/~ehood/MIME/2046/rfc2046.html#6. So, X-application/bibframe+xml;q=0.00 :) No need to seek standards approval for that. Ralph ________________________________ From: SRU (Search and Retrieve Via URL) Implementors <[log in to unmask]> on behalf of Ray Denenberg <[log in to unmask]> Sent: Wednesday, February 19, 2014 5:44 PM To: [log in to unmask] Subject: Re: SRU recordPacking and JSON Just so I'm clear Ralph, your idea of record content negotiation depends on the adoption of a new parameter for this purpose? Also please clarify: Nevermind XML vs. json for the moment. Suppose I want records in MODS, but if that's not available, I'll take MARCXML. Your suggestion is that both of these would be specified by their mime type - and it happens that both of these have mime types - but what if my third choice is, say, BIBFRAME? Then you're suggesting that the only way to do this is to register a BIBFRAME mime type? Ray > -----Original Message----- > From: SRU (Search and Retrieve Via URL) Implementors > [mailto:[log in to unmask]] On Behalf Of LeVan,Ralph > Sent: Wednesday, February 19, 2014 5:02 PM > To: [log in to unmask] > Subject: Re: SRU recordPacking and JSON > > You are absolutely correct. The correct negotiation request would be: > application/ld+json, application/json;q=0.9 > > That says, I want JSONLD, but will accept any JSON. I *don't* get to > just pick another JSON format if they asked only for ld+json. But, > given the recordAccept (yes, I just coined that name now) parameter > above, I *would* be allowed to return application/vnd.oclc.viaf+json if > I wasn't able to return application/ld+json. > > Ralph > > -----Original Message----- > From: SRU (Search and Retrieve Via URL) Implementors > [mailto:[log in to unmask]] On Behalf Of Jonathan Rochkind > Sent: Wednesday, February 19, 2014 4:44 PM > To: [log in to unmask]<mailto:[log in to unmask]> > Subject: Re: SRU recordPacking and JSON > > I'm wondering whether it actually makes sense at all to content > negotiate to a different JSON-based format then the one you think they > are asking for? > > Does someone have a use case where software asking for one JSON-based > format, but which gets a different JSON-based format instead, is still > going to be able to do something useful with it? It's not something > I've encountered myself. > > Even for "+xml" content types (which actually are standardized -- every > content type ending in "+xml" must, by standard, be an XML type; the > same is not true of "+json") -- I don't _think_ conneg usually works > such that a client asking for only "something+xml" is given "other+xml" > instead -- rather than an error message saying "something+xml" can not > be provided. > > > On 2/19/14 4:13 PM, LeVan,Ralph wrote: > >> Sure, it's just as sensible, the concept is good. But how you go > >> about > > doing content > > > >>negotiation at the record level? Can you give an example. > > > > > http://rdap02pxdu.dev.oclc.org:8080/viaf/search?query=local.names+all+ > > %22ralph%20levan%22&httpAccept=application/json > > > > Here's a generic request for an SRU response in JSON. It doesn't say > > anything about how the records should be returned, but certainly > > implies that they should be in JSON too. (Sadly, it gets an XML > > record now, because I'm not doing record content negotiation yet.) > > Right now, I have two different JSON schemas: vnd.oclc.viaf+json > > (that's my VIAF XML record run through a lovely mechanical XML->JSON > > translator) and ld+json (that's a hand-built implementation of the > > current Linked Data in JSON proposal). I'd propose specifying them > > using recordSchema (that being the closest match we have.) > > > > > http://rdap02pxdu.dev.oclc.org:8080/viaf/search?query=local.names+all+ > > %22ralph%20levan%22&httpAccept=application/json&recordSchema=applicat > i > > on/ld%2Bjson(Sadly, that URL gets you a nice SRU diagnostic returned > > as JSON, because that recordSchema isn't recognized yet. I'm really > > hoping for some feedback on the idea before I implement record > content > > negotiation.) > > > > Now, if they asked for application/bob+json, then we fall into > regular > > HTTP negotiation and I'd return what I thought was my best JSON and > > I'd tell them they were getting application/vnd.oclc.viaf+json in the > > recordSchema element (or whatever they get called in JSON) of the > > record response. > > > > Ralph > > > > p.s. Here's the hack I'm using right now to get that VIAF record in > > JSON. Like I said, I'm looking for a cleaner way to do this that > > doesn't make you all gag. J > > > > > http://rdap02pxdu.dev.oclc.org:8080/viaf/search?query=local.names+all+ > > %22ralph%20levan%22&recordPacking=string&recordSchema=JSON&httpAccept > = > > application/json > >