Bug 6594 - Add schema.org microdata
Summary: Add schema.org microdata
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Owen Leonard
QA Contact: Bugs List
URL:
Keywords:
Depends on:
Blocks: 11190
  Show dependency treegraph
 
Reported: 2011-07-16 12:10 UTC by Magnus Enger
Modified: 2014-05-26 21:04 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 6594: Schema.org structured data for OPAC display (18.59 KB, patch)
2013-08-22 15:56 UTC, Jared Camins-Esakov
Details | Diff | Splinter Review
Bug 6594: Move subject keywords schema.org markup into <span> element (2.28 KB, patch)
2013-08-22 15:56 UTC, Jared Camins-Esakov
Details | Diff | Splinter Review
Bug 6594: Correct schema.org context for item status (1.72 KB, patch)
2013-08-22 15:56 UTC, Jared Camins-Esakov
Details | Diff | Splinter Review
Bug 6594: Schema.org span nesting improvements (3.90 KB, patch)
2013-08-22 15:57 UTC, Jared Camins-Esakov
Details | Diff | Splinter Review
Bug 6594: Schema.org structured data for OPAC display (18.65 KB, patch)
2013-08-28 11:07 UTC, Chris Cormack
Details | Diff | Splinter Review
Bug 6594: Move subject keywords schema.org markup into <span> element (2.34 KB, patch)
2013-08-28 11:07 UTC, Chris Cormack
Details | Diff | Splinter Review
Bug 6594: Correct schema.org context for item status (1.77 KB, patch)
2013-08-28 11:07 UTC, Chris Cormack
Details | Diff | Splinter Review
Bug 6594: Schema.org span nesting improvements (4.05 KB, patch)
2013-08-28 11:08 UTC, Chris Cormack
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Magnus Enger 2011-07-16 12:10:03 UTC
Would it be a good idea to add schema.org microdata to the OPAC, as described here? http://go-to-hellman.blogspot.com/2011/07/spoonfeeding-library-data-to-search.html

See also: 
http://schema.org/CreativeWork
http://schema.org/Book

There are several types that might be relevant, not just Book.
Comment 1 Dan Scott 2013-08-22 11:21:59 UTC
https://github.com/dbs/Koha/tree/schema.org may be of interest; thanks to Chris Cormack for taking the time to point me at the OPAC XSLT.

I have tested the XSLT from the command line, but the TT2 changes for the holdings markup in the OPAC are as of yet untested. This is meant as a quick proof of concept at this point (although if someone else tries it out and it works for them, feel free to use the code!).

The mappings from MARC & holdings to schema.org types & properties are based on similar work I have done with Evergreen and VuFind, informed by my participation in the W3C Schema Bib Extend community group.
Comment 2 Jared Camins-Esakov 2013-08-22 15:56:36 UTC Comment hidden (obsolete)
Comment 3 Jared Camins-Esakov 2013-08-22 15:56:45 UTC Comment hidden (obsolete)
Comment 4 Jared Camins-Esakov 2013-08-22 15:56:53 UTC Comment hidden (obsolete)
Comment 5 Jared Camins-Esakov 2013-08-22 15:57:10 UTC Comment hidden (obsolete)
Comment 6 Chris Cormack 2013-08-28 11:07:23 UTC
Created attachment 20697 [details] [review]
Bug 6594: Schema.org structured data for OPAC display

To support schema.org processors, such as Google, Bing, and Yandex,
structure our data so that it has machine-readable attributes. This pass
declares the CreativeWork sub-types as well as Product for the main
bibliographic record details, and uses the Offer type for holdings
information per the W3C Schema Bib Extend community group discussions.

Signed-off-by: Dan Scott <dan@coffeecode.net>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Comments on final patch.

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Comment 7 Chris Cormack 2013-08-28 11:07:33 UTC
Created attachment 20698 [details] [review]
Bug 6594: Move subject keywords schema.org markup into <span> element

Google's rich snippets tool gets confused by the <a property="keywords">
approach, so stuff another span inside the <a> element to remove
confusion with the href attribute.

Signed-off-by: Dan Scott <dan@coffeecode.net>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Comment 8 Chris Cormack 2013-08-28 11:07:42 UTC
Created attachment 20699 [details] [review]
Bug 6594: Correct schema.org context for item status

We were inserting the <link> element inside an open <td> element, which
HTML parsers, even the most forgiving, do not like very much.

Signed-off-by: Dan Scott <dan@coffeecode.net>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Comment 9 Chris Cormack 2013-08-28 11:08:00 UTC
Created attachment 20700 [details] [review]
Bug 6594: Schema.org span nesting improvements

So, it turns out that the <a href> was causing a new "chain" to be
invoked, thus nesting the <span> elements for properties within the <a
href> actually caused the properties to be attached to that new chain
rather than the containing object. Therefore, wrap the <span> elements
around the <a href> elements where applicable.

Thanks to Manu Sporny in #rdfa for helping me to sort this out.

Signed-off-by: Dan Scott <dan@coffeecode.net>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
I tested by validating against the Google rich snippet tool,
validator.nu, and linter.structured-data.org. All were satisfied
with the microdata markup, and the properties that are set make
sense.

These patches are only for MARC21 XSLT view, but I think it is worth
pushing them even without the NORMARC and UNIMARC markup, so that
people can start to test out schema.org microdata in Koha, and
refine the implementation.

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>

FWIW I agree with Jared, it is essentially a no-op in terms of what
the user sees, so is safe.
Comment 10 Galen Charlton 2013-08-28 14:01:07 UTC
Pushed to master.  Thanks, Dan!  And congratulations on your first patch series to Koha!
Comment 11 Mathieu Saby 2013-08-28 16:00:47 UTC
Could you tell me if a followup for UNIMARC is needed ?

M. Saby
Comment 12 Dan Scott 2013-09-03 22:58:44 UTC
(In reply to mathieu saby from comment #11)
> Could you tell me if a followup for UNIMARC is needed ?

Yes, at this point only support for MARC21 has been created and merged. I'm not at all familiar with UNIMARC, thus equivalent XSLT changes for UNIMARC would be great. I would be happy to help vet the HTML+RDFa output from any such changes!
Comment 13 Mathieu Saby 2013-09-04 07:12:08 UTC
I will open a specific bug for unimarc and try to take a look.

Mathieu
Comment 14 Magnus Enger 2013-09-05 09:03:07 UTC
I have added "Bug 10826 - Add schema.org microdata for NORMARC"
Comment 15 Mathieu Saby 2013-09-05 15:57:09 UTC
And I added Bug 10830 for Unimarc.
Comment 16 Frédéric Demians 2013-11-02 17:50:09 UTC
The goal of embedding Schema.org microformat structured data into Koha OPAC biblio records is to improve catalog indexing by web crawlers like Google. Consequently wouldn't be interesting to provide to crawler a complete sitemap:

  http://sitemaps.org

I have a script for that:

https://metacpan.org/pod/release/FREDERICD/Koha-Contrib-Tamil-0.032/bin/koha-sitemap
Comment 17 Magnus Enger 2013-11-02 18:19:09 UTC
(In reply to Frédéric Demians from comment #16)
> The goal of embedding Schema.org microformat structured data into Koha OPAC
> biblio records is to improve catalog indexing by web crawlers like Google.
> Consequently wouldn't be interesting to provide to crawler a complete
> sitemap:

That would be Very Cool! But on a new bug, I guess?