I strongly disagree; it isn't that CQL is a poor query language - its that
LOM is NOT a search vocabulary.

The answer is to build a proper context set for LOM that can be queried
efficiently. (An example I believe made it into the appendices for the IMS
DRI specification, but I may be wrong!)

Xquery is not the answer as it request that the physical encoding of the
metadata must be XML, which will break federated search across other
repositories with different physical storage - something the CQL was
designed to abstract away from in the first place.

- S

On 14/9/04 9:28 am, "Chris Hubick" <[log in to unmask]> wrote:

> On Mon, 2004-09-13 at 15:30, Boon Low wrote:
>> bib1) via d+ services as show in the request exemplars. Comparing to
>> DC, using to LOM context sets seem tedious. For example it is not
>> straight forward to specific an author search because LOM uses 'source
>> & value' tree pair to specify an author entry, there is no author field
>> at such. An author LOM CQL search would be (assuming LOM vocab!):
>> (LOM.LifeCycle.Contribute.Role.Value = "author") and
>> (LOM.LifeCycle.Contribute.Entry.String = "XXXX") ! Now compare this
>> with author=XXX or dc.creator=XXX ..
>
> You have hit on *the* major problem with all this.
>
> It's more than just tedious, it's downright *broken*.  This is due to a
> limitation of the CQL language when querying LOM...
>
> The real problem is that, using your example, the left and right
> arguments to the 'AND' will be evaluated separately, in different
> contexts, and then have their results combined later...
>
> That is to say, the system will first run a search through the
> repository, identifying the set of records where:
>
> (LOM.LifeCycle.Contribute.Role.Value = "author")
>
> This will include *all* records which specify an (any) author.
>
> *Independently* of those results, another search will be run,
> identifying records where:
>
> (LOM.LifeCycle.Contribute.Entry.String = "XXXX")
>
> This will match on any record that 'XXXX' contributed to, no matter what
> their role was in that particular contribution!!
>
> The 'AND' will then be applied, and you will be left with all records in
> which 'XXXX' contributed in ANY way, AND which their was also some
> 'author' type contribution by ANY author.
>
> Though this obviously isn't what the author of that query intended, I
> believe it is technically the correct behavior according to CQL.
>
> There is no way I can see this problem easily rectified within the CQL
> query syntax.  It was just not designed to query hierarchical data such
> as LOM.  The real/ideal solution is to use a more powerful query
> language such as XPath/XQuery.
>
>> Do you think
>> there should be a common [LOM] context set/profile? Or this is something we
>> should be addressing?
>
> I think it would be great if there were such a document.  Indeed, I
> looked for one, and later thought of writing up what I had done as one.
> As with everything though, it's a matter of time to do so. :)
>
> Note that you are only seeing the subset of indexes that are in fact
> exposed as searchable by our specific repository implementation.  That
> is to say, the complete LOM index list would be larger than that
> currently returned by our 'explain' response.  Notably missing are
> Langstring 'language' indexes, such as
> 'LOM.General.Title.String.Language'.  This is because these are largely
> useless within the context of CQL, due to the problem cited above.  I
> would be happy to create a complete LOM index list upon request, if
> someone wants to formalize it into a specification for submission to the
> ZING agency.
>
>
> Additional Geek Implementation Notes:
>
> The list of indexes provided are a direct result of work on my Java LOM
> Binding  http://adlib.athabascau.ca/~hubick/LOM/
> This binding is not just for exposing instance data, but also defines a
> complex hierarchy of static 'TYPE' classes for each LOM field.  The
> textual SRU indexes you see are created from the hierarchy of those
> types.  The Javadoc for the base type class is here:
> http://adlib.athabascau.ca/~hubick/LOM/apidocs/org/ieee/ltsc/lom/DataElementTy
> pe.html
>
> Also defined is a LOMImplementation interface which exposes the list of
> static TYPE's supported by a particular LOM implementation (which may
> support additional custom LOM field types).
> http://adlib.athabascau.ca/~hubick/LOM/apidocs/org/ieee/ltsc/lom/LOMImplementa
> tion.html
>
> The SRU search functionality is all built on top of my Learning Object
> Repository (LOR) Java interface:
> http://adlib.athabascau.ca/~hubick/LOR/
> So, the code will work with any repository implementing the required
> primitive functions from that interface.  The main primitive function
> being 'searchLOMRecords', which, supplied a phrase string and a field
> name, returns a list of record identifiers:
> http://adlib.athabascau.ca/~hubick/LOR/apidocs/ca/edusource/lor/LOR.LOMSearch.
> html
>
> --
> Chris Hubick
> mailto:[log in to unmask]
> mailto:[log in to unmask]
> http://adlib.athabascau.ca/~hubick/
> http://www.hubick.com/
>
>
> __
>   This communication is intended for the use of the recipient to whom it
>   is addressed, and may contain confidential, personal, and or privileged
>   information. Please contact us immediately if you are not the intended
>   recipient of this communication, and do not copy, distribute, or take
>   action relying on it. Any communications received in error, or
>   subsequent reply, should be deleted or destroyed.
> ---