5 Responses to A better beta – Open Search Version 2.0

  1. MikeT says:

    I have a few thoughts/notes:

    - Bibliographic ‘Source publication date’: Currently the interface attempts to search for appropriate date information from this field when using this data (e.g. the automatically generated references). A year, generally being a 4 digit number, is simple enough to pick out in most cases (probably all cases so far). Months/seasons can be picked out in text but not numerically as the can clash with days. The more specific the data in this field is, the better it is for us really though, as long as there is reasonable consistency in the way in which the data is entered.

    - Publisher searching: This is actually working perfectly well as it was never switched to perform just a general search as was the case with the Author search.

    - Technical format for research: Whether it will always be PDF for research I wouldn’t like to say 100%, but I suspect that the other formats that may occasionally be used would not need to be searched for explicitly (e.g. PostScript .ps format). They could be converted to PDF before upload in any case.

    - Journal item/article terminology: Can this change be made in the back-end database on a one off basis by Intrallect?

    - DOI search: Actually searches any LOM->identifier entries (this includes the unique identifier generated by intraLibrary for each record) and also searches the lom:technical->lom:location data (we tend to use this for the displayed ‘published/external URL’. Generally speaking this won’t actually cause a problem.

    I think that’s all of it.

    MT

    • Nick says:

      Thanks Mike

      I stand corrected on Publisher searching – as this is another instance of the contributor field set I assumed the same issue would arise as searching for Author. I’m not absolutely clear why this isn’t the case – is it just because it’s a less sophisticated requirement (i.e. Just one consistent string for Publisher whereas there may be multiple authors, often with common first names/surnames?

      • MikeT says:

        The difference is how the fields in LOM get mapped onto field in Dublin Core (which is what the searches are really querying). Publishers are considered separate from creators (authors) and are under different fields in DC – dc:publisher and dc:creator respectively.

        I never altered the interface to use the general query instead of querying dc:publisher, it fixed itself when intraLibrary was updated.

  2. Nick says:

    Technical format for research: I do anticipate using PDF only and converting any other formats we might receive – fairly typical for OA archives of research I think though some also support Word. This shouldn’t be a problem while we are fully mediated though I guess there may be issues if we ever go to author self-archiving. Assuming research is PDF only then we clearly don’t need 70 MIME types supported in an advanced search for research – or even a fraction of them. Instead, could we perhaps just have a checkbox for “Full text”?

  3. Nick says:

    Just to add also that it may be worth looking at the advanced search functionality offered by JorumOpen to inform our own advanced search. JorumOpen will go live in January (19th I think) but you can see a video “Searching & Browsing JorumOpen” at http://community.jorum.ac.uk/course/view.php?id=40

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: