|
Description
Magnus Enger
2011-07-16 12:10:03 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. Created attachment 20566 [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. Created attachment 20567 [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> Created attachment 20568 [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> Created attachment 20569 [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. 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> 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> 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> 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. Pushed to master. Thanks, Dan! And congratulations on your first patch series to Koha! Could you tell me if a followup for UNIMARC is needed ? M. Saby (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! I will open a specific bug for unimarc and try to take a look. Mathieu I have added "Bug 10826 - Add schema.org microdata for NORMARC" And I added Bug 10830 for Unimarc. 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 (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? |