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]

> 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

> >