[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [search-ws] sru:recordPacking = unpacked ?
Sorry, but this doesn't make any sense. If you want to do OpenSearch,
why don't you just return an RSS or Atom response? If you do that, then
you'll somehow do the transform from SRU to RSS/Atom on the server side
and you'll be the only one to know how complex the logic was to find the
necessary elements.
Ralph
> -----Original Message-----
> From: Hammond, Tony [mailto:t.hammond@nature.com]
> Sent: Wednesday, August 19, 2009 11:57 AM
> To: search-ws@lists.oasis-open.org
> Cc: Hammond,Tony
> Subject: [search-ws] sru:recordPacking = unpacked ?
>
> Hi:
>
> I have a requirement for handling SRU record data to make it
accessible
> within an OpenSearch context. Essentially I need to "unpack" the
record
> data.
>
> To explain this scenario I will use the example "Atom extension for
SRU"
> format [1] which is posted on the TC site.
>
> This is a good start to the item level SRU mapping. So, for a result
set
> delivered in the "srw_dc" schema I might have something like:
>
> <title>
> <link>
> <sru:recordSchema>...</sru:recordSchema>
> <sru:recordPacking>...</sru:recordPacking>
> <sru:recordData>
> <srw_dc>
> <dc:title>
> <dc:creator>
> </srw_dc>
> </sru:recordData>
> <sru:recordPosition>...</sru:recordPosition>
>
> This is good from an SRU point of view but not so good from an
OpenSearch
> point of view as the search response elements ("dc:title",
"dc:author") are
> buried two levels down in the element hierarchy.
>
> And this is significantly worse in my own use case of PAM, or PRISM
> Aggregator Message, where there are two more wrapper elements
intervening.
> So I would have this:
>
> <sru:recordData>
> <pam:message>
> <pam:article>
> <xhtml:header>
> <dc:title>
> <dc:creator>
> </xhtml:header>
> </pam:article>
> </ pam:message>
> </sru:recordData>
>
> From an OpenSearch point of view what I really need is this:
>
> <title>
> <link>
> <dc:title>
> <dc:creator>
> <sru:recordSchema>...</sru:recordSchema>
> <sru:recordPacking>...</sru:recordPacking>
> <sru:recordData/>
> <sru:recordPosition>...</sru:recordPosition>
>
> That is, I need something akin to an "unpacked" option, so that my
search
> response elements are immediately available at the toplevel and not
buried
> within a hierarchy. The reason for this is not so much technical
(although
> it is that too) but is to do with mindshare. If it's too hard nobody
will
> bother and SRU is the loser. (SRU must accommodate OpenSearch, not the
> other
> way round.)
>
> Note that we already have the request parameter "recordPacking" which
takes
> two values "xml" and "string". (And frankly, not doing very much IMHO.
Badly
> formed XML is already something outside of the SRU conventions -
schema
> then
> amounts for nothing.)
>
> (I believe this is the right parameter to focus on rather than
introduce a
> new parameter, e.g. "recordDataPacking".)
>
> I wonder if it would be possible to either a) overload this parameter,
or b)
> substitute the application of this parameter, so that the following
cases
> could be requested:
>
> a) recordPacking = packed
>
> b) recordPacking = flattened
>
> c) recordPacking = unpacked
>
> The first case a) would be the standard SRU offering, the second case
would
> allow for properties to bubble up to the <recordData> container
element, and
> the third case c) would allow for properties to escape the SRU
response
> entirely and be directly available to the host format (e.g. Atom in
this
> example).
>
> Note that the "unpacked" option would not apply to native SRU response
XML
> which has nowhere to put this data - there is no "outside".
>
> Note also that the "flattened" option may be too much to think about.
It is
> a logical possibility but may just complicate matters.
>
> So, the three cases could look as folows:
>
> a) recordPacking = packed
>
> <title>
> <link>
> <sru:recordSchema>...</sru:recordSchema>
> <sru:recordPacking>...</sru:recordPacking>
> <sru:recordData>
> <srw_dc>
> <dc:title>
> <dc:creator>
> </srw_dc>
> </sru:recordData>
> <sru:recordPosition>...</sru:recordPosition>
>
>
> b) recordPacking = flattened
>
> title>
> <link>
> <sru:recordSchema>...</sru:recordSchema>
> <sru:recordPacking>...</sru:recordPacking>
> <sru:recordData>
> <dc:title>
> <dc:creator>
> </sru:recordData>
> <sru:recordPosition>...</sru:recordPosition>
>
> c) recordPacking = unpacked
>
> <title>
> <link>
> <dc:title>
> <dc:creator>
> <sru:recordSchema>...</sru:recordSchema>
> <sru:recordPacking>...</sru:recordPacking>
> <sru:recordData/>
> <sru:recordPosition>...</sru:recordPosition>
>
>
> Of course, we still have the existing values for "recordPacking"
which, if
> required still, could be accommodated by adopting a value list
strategy,
> similar to "sortKeys", e.g. we could have
>
> * recordPacking = xml
>
> * recordPacking = xml, packed
>
> * recordPacking = xml, flattened
>
> * recordPacking = xml, unpacked
>
> and same for "string".
>
> It could be argued that an "unpacked" record data is no longer a valid
SRU
> response, but I would counter that not all responses have recoprd
data, e.g.
> where diagnostics are provided. Also, even in an "unpacked" scenario
with an
> empty "recordData" element (or missing element) we have said something
about
> the data: that is was there but has been processed ("unpacked").
>
> I would like to hear some responses to this proposal as I will very
shortly
> have to go ahead and implement search responses for the service we are
about
> to release. I would like to be as fully SRU compatible as possible but
also
> making it a breeze for OpenSearch users. I believe that the current
proposal
> (or something very much like it) would allow for both perspectives to
be
> maintained.
>
> Cheers,
>
> Tony
>
>
> [1]
>
http://www.oasis-open.org/committees/download.php/33408/atom-extension-f
or-
> s
> ru.xml
> [2]
>
http://www.crossref.org/CrossTech/2009/07/opensearch_formats_for_review.
ht
> ml
>
>
>
************************************************************************
********
> 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
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]