I'm finally able to make some sense out of thi, I
think. The concrete example (that I am finally able to uncover from those
pesky URLs) is a JSON file, and my questions are:
- Is this a meaningful issue only when the
response format is other than XML?
- Or Is it meaningful when the response format is
XML but not the standard SRU response (e.g. ATOM)?
- This seems to assume that there is a
cannonical (or natural) mapping of the SRU Response format in its XML form to a
JSON form. So "unpack" is a directive to use a variation of the
form. First of all I'm not sure that the first assumption is valid
(although I don't know enough about JSON to know for sure) but second, why not
just define a concrete JSON schema that prescribes this alternative
format?
- And if the answer to the second question is yes,
then the same would apply to an XML format like ATOM.
I hope these questions make sense.
--Ray
----- Original Message -----
Sent: Friday, September 18, 2009 12:45
PM
Subject: 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" <rden@loc.gov>
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" <t.hammond@nature.com <mailto:t.hammond@nature.com>
> To: "Ray Denenberg, Library of Congress"
<rden@loc.gov <mailto:rden@loc.gov> >; <search-ws@lists.oasis-open.org <mailto:search-ws@lists.oasis-open.org>
> 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" <rden@loc.gov <mailto:rden@loc.gov> > 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>
|