Title: Re: [search-ws] sru:recordPacking = unpacked ?
Hi Ray:
Seems like we’re moving like ships in the night. Not quite sure where the difficulty lies. (Well I do. I guess it’s coming to terms with alternative formats for SRU disclosure.) The example you attached is for an SRU/XML response. An ‘unpacked’ record could have no other logical effect than to remove the data (or to ignore the request). I thought this was clear from the writeup:
“For the standard SRU XML response, a value of 'unpacked' would have the effect of simply removing the data content from the 'recordData' field. For other open SRU host formats, a value of 'unpacked' would relocate the data from the 'recordData' field up to a higher level within the item level unit of the response.”
So the effect on the SRU/XML example you sent me would presumably be as below – entirely logical but not too useful since the data is vanished away! The JSON example I sent in my mail shows packed./unpacked variations.
The real reason for this parameter value setting is twofold: 1) to allow SRU responses to be hosted by other carrier formats than SRU/XML, and 2) to allow the data in an sru:recordData field to migrate to a more visible place within the carrier format’s item container. Note the data is still managed within the item (=record) container so there is no possibility of data wandering across item container boundaries.
The URLs I sent (unless broken by mail text wrap) would show the effect in a live environment.
Cheers,
Tony
==
<zs:searchRetrieveResponse>
<zs:version>1.1</zs:version>
<zs:numberOfRecords>2043</zs:numberOfRecords>
<zs:records>
<zs:record>
<zs:recordSchema>info:srw/schema/1/dc-v1.1</zs:recordSchema>
<zs:recordPacking>unpacked</zs:recordPacking>
<zs:recordData>
<srw_dc:dc xsi:schemaLocation="info:srw/schema/1/dc-schema http://www.loc.gov/standards/sru/resources/dc-schema.xsd">
</srw_dc:dc>
</zs:recordData>
<zs:recordPosition>2</zs:recordPosition>
</zs:record>
<zs:record>
<zs:recordSchema>info:srw/schema/1/dc-v1.1</zs:recordSchema>
<zs:recordPacking>unpacked</zs:recordPacking>
<zs:recordData>
<srw_dc:dc xsi:schemaLocation="info:srw/schema/1/dc-schema http://www.loc.gov/standards/sru/resources/dc-schema.xsd">
</srw_dc:dc>
</zs:recordData>
<zs:recordPosition>3</zs:recordPosition>
</zs:record>
</zs:records>
==
On 18/9/09 15:00, "Ray Denenberg, Library of Congress" <> wrote:
Thanks for this, Tony, but unfortunatey it does not clear up my confusion. I am still left with the impression that this does not recognize the case where there is more than a single record in the response. What I would like to see is an example of the alternative form that you suggest as applied to a response that has, say, two records.
Please see the attached file representing an SRU response, and re-write it according to your proposed alternative format. Thanks. --Ray
----- Original Message -----
From: "Hammond, Tony" < <mailto:> >
To: "Ray Denenberg, Library of Congress" < <mailto:> >; < <mailto:> >
Sent: Thursday, September 17, 2009 11:40 AM
Subject: Re: [search-ws] sru:recordPacking = unpacked ?
> Hi Ray:
>
> As requested a full writeup of recordPacking attached as a Word doc.
>
> Note that my proposal is merely a generalization of the existing
> recordPacking parameter. And I have in fact relented on my earlier view on
> 'string' and think that this is OK now and can be just regraded as a fairly
> loose data disposition.
>
> So, all I am doing is recognizing that SRU responses can be mapped to
> external host carrier formats and that the data does not need to be (and
> usually is best not) confined to a nested position in the response
> organization but can made available immediately under the item level unit.
>
> The attached writeup has suitably opaque wording I think for a standards
> doc. :)
>
> Example URLs are listed below (on our dev-server) to illustrate this in
> practice: 1-3A are for RSS, 1-3B are for JSON (actually JSONP which is
> easier to read as of media type text/javascript). (You can anyway run new
> examples from the form page at the base URL.)
>
> Also for ready reference is an example hosted format (JSON) below which
> shows both packed and unpacked record data. (The unpacked record data
> bubbles up to the top of the item level container.)
>
> Cheers,
>
> Tony
>
>
>
> == Example URLs ==
>
> 1A. RSS - default record packing (xml)
>
> http://dev-www.nature.com/opensearch/request?query=vampire&httpAccept=application%2Frss%2Bxml <http://dev-www.nature.com/opensearch/request?query=vampire&httpAccept=application%2Frss%2Bxml>
>
>
> 2A. RSS - explicit record packing (xml)
>
> http://dev-www.nature.com/opensearch/request?query=vampire&httpAccept=applic <http://dev-www.nature.com/opensearch/request?query=vampire&httpAccept=applic>
> ation%2Frss%2Bxml&recordPacking=xml
>
> 3A. RSS - explicit record packing (unpacked)
>
> http://dev-www.nature.com/opensearch/request?query=vampire&httpAccept=applic <http://dev-www.nature.com/opensearch/request?query=vampire&httpAccept=applic>
> ation%2Frss%2Bxml&recordPacking=unpacked
>
>
> 1B. JSON - default record packing (xml)
>
> http://dev-www.nature.com/opensearch/request?query=vampire&httpAccept=text%2 <http://dev-www.nature.com/opensearch/request?query=vampire&httpAccept=text%2>
> Fjavascript
>
>
> 2B. JSON - explicit record packing (xml)
>
> http://dev-www.nature.com/opensearch/request?query=vampire&httpAccept=text%2 <http://dev-www.nature.com/opensearch/request?query=vampire&httpAccept=text%2>
> Fjavascript&recordPacking=xml
>
> 3B. JSON - explicit record packing (unpacked)
>
> http://dev-www.nature.com/opensearch/request?query=vampire&httpAccept=text%2 <http://dev-www.nature.com/opensearch/request?query=vampire&httpAccept=text%2>
> Fjavascript&recordPacking=unpacked
>
>
> == Example Hosted Format (JSON) ==
>
> ** SRU Packed Data (JSON)
>
> "entry": [
> {
> "title": "The role of junctional adhesion molecules in
> vascular inflammation",
> "link": "http://dx.doi.org/10.1038/nri2096 <http://dx.doi.org/10.1038/nri2096> ",
> "id": "doi:10.1038/nri2096",
> "updated": "2009-08-28T12:46:43+00:00",
> "content": null,
> "sru:recordSchema": "info:srw/schema/11/pam-v2.1",
> "sru:recordPacking": "xml",
> "sru:recordData": {
> "pam:message": {
> "pam:article": {
> "xhtml:head": {
> "dc:identifier": "doi:10.1038/nri2096",
> "dc:title": "The role of junctional adhesion
> molecules in vascular inflammation",
> "dc:creator": [
> "Christian Weber",
> "Line Fraemohs",
> "Elisabetta Dejana"
> ],
> ... and prism properties ...
> }
> }
> }
> },
> "sru:recordPosition": 1
> },
> ...
> ]
>
>
> ** SRU Unpacked Data (JSON)
>
> "entry": [
> {
> "title": "The role of junctional adhesion molecules in
> vascular inflammation",
> "link": "http://dx.doi.org/10.1038/nri2096 <http://dx.doi.org/10.1038/nri2096> ",
> "id": "doi:10.1038/nri2096",
> "updated": "2009-08-28T12:45:42+00:00",
> "content": null,
> "dc:identifier": "doi:10.1038/nri2096",
> "dc:title": "The role of junctional adhesion molecules in
> vascular inflammation",
> "dc:creator": [
> "Christian Weber",
> "Line Fraemohs",
> "Elisabetta Dejana"
> ],
> ... and prism properties ...
> "sru:recordSchema": "info:srw/schema/11/pam-v2.1",
> "sru:recordPacking": "unpacked",
> "sru:recordData": {
> "pam:message": {
> "pam:article": {
> "xhtml:head": {
> }
> }
> }
> },
> "sru:recordPosition": 1
> },
> ...
> ]
>
> ==
>
>
>
>
>
>
> On 15/9/09 19:15, "Ray Denenberg, Library of Congress" < <mailto:> > wrote:
>
>> Tony, could you please prepare a complete writeup of this issue, including
>> examples, that we can walk through at next Monday's call. I'm still having
>> trouble figuring it out. By Friday, if possible? Thanks. --Ray
>>
>>
>>
>
>
> ********************************************************************************
> DISCLAIMER: This e-mail is confidential and should not be used by anyone who is
> not the original intended recipient. If you have received this e-mail in error
> please inform the sender and delete it from your mailbox or any other storage
> mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
> liability for any statements made which are clearly the sender's own and not
> expressly made on behalf of Macmillan Publishers Limited or one of its agents.
> Please note that neither Macmillan Publishers Limited nor any of its agents
> accept any responsibility for viruses that may be contained in this e-mail or
> its attachments and it is your responsibility to scan the e-mail and
> attachments (if any). No contracts may be concluded on behalf of Macmillan
> Publishers Limited or its agents by means of e-mail communication. Macmillan
> Publishers Limited Registered in England and Wales with registered number 785998
> Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
> ********************************************************************************
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php <https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php>
