HugoBlox / hugo-blox-builder

🚨 GROW YOUR AUDIENCE WITH HUGOBLOX! 🚀 HugoBlox is an easy, fast no-code website builder for researchers, entrepreneurs, data scientists, and developers. Build stunning sites in minutes. 适合研究人员、企业家、数据科学家和开发者的简单快速无代码网站构建器。用拖放功能、可定制模板和内置SEO工具快速创建精美网站!
https://hugoblox.com/templates/
MIT License
8.2k stars 2.9k forks source link

Flesh out JSON+LD #1604

Closed HughP closed 4 years ago

HughP commented 4 years ago

Greetings,

I am reading through the JSON+LD metadata files in the Academic Theme and I would appreciate some feedback (or guidance) from other theme users.

  1. I would like more metadata loaded into the JSON+LD payload.
  2. I am not sure if from a theme maintenance perspective if there is "reasonable resistance" i.e. pursuing minimalism to adding more metadata to the payload or if this is just "nice work to be done"... So, I am wondering what the best way to go about generating discussion and action might be. — should conversation be done here or should it happen over on Spectrum? Links and such might be cleaner on github. In the past I have raised issues on github: https://github.com/gcushen/hugo-academic/issues/413, https://github.com/gcushen/hugo-academic/issues/479.
  3. I would like to contribute my alterations back to the theme if they are useful and welcomed. But I need feedback on both points.
  4. I am looking for social affirmation that I am understanding the goals and performance of the discussed technology. So, please educate me as we go a long - I don't want to spit in the wind here. I am also open to quick video chats on google or skype if that sort of discussion is faster than typing. I'm in Western Europe but can be available most any time of the day (within reason).

Two examples for discussion and improvement:

  1. in the template https://github.com/gcushen/hugo-academic/blob/c5b26892a9c6edd861c86993fce1c4cc234b9408/layouts/partials/jsonld/article.html (Which is a template for generating the JSON+LD payload. The template terms used seem to refer, per schema.org parlance, to blog posts, which would be articles of the website https://schema.org/Article, rather than academic articles https://schema.org/ScholarlyArticle) around line #32 there is a conditional {{with author}} this works for single author pages, but does not work with two (or more) authored pages. Is this a bug? or is this a "design feature"? can someone help me understand this particular situation?

In general it is unclear to me if the goal of /article.html is just about describing blog posts — single pages which are part of the website, or if it is also about describing a publication which a particular webpage might be describing? If it is about describing blog posts then it would appear that the schema.org recommendation is to use https://schema.org/blogPost or https://schema.org/blogPosting be used. and https://schema.org/blogPosts on agregation pages like taxonomy lists. Some clear feedback here would be appreciated.

  1. The template for the main page does not seem to provide very rich metadata to the payload. I assume the main page (landing page) should deliver the following three components in the payload (description of the total website, description of the main page, description of the creative works described on the main page) If we take the possible payload for the total website https://schema.org/WebSite It seems that contributor and copyright date are both things which we set up in our config.toml file and which are accessible via params so, they could theoretically be added to the JSON+LD payload. Is there a compelling story as to why they are not currently included? (I present a brief look at the uses of the Hugo-Academic and schema.org terms in a gist) per https://github.com/gcushen/hugo-academic/blob/c5b26892a9c6edd861c86993fce1c4cc234b9408/layouts/partials/jsonld/website.html

Again I seek feed back and information about the narrative for development. should I fork and send small commits?

stale[bot] commented 4 years ago

This issue has been automatically marked as stale because it has not had any recent activity. The resources of the Academic team are limited, and so we are asking for your help. If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open. If this is a feature request, and you feel that it is still relevant and valuable, please tell us why. This issue will automatically close soon if no further activity occurs. Thank you for your contributions.

HughP commented 4 years ago

Issues #1664 and #1663 are related.

stale[bot] commented 4 years ago

This issue has been automatically marked as stale because it has not had any recent activity. The resources of the Academic team are limited, and so we are asking for your help. If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open. If this is a feature request, and you feel that it is still relevant and valuable, please tell us why. This issue will automatically close soon if no further activity occurs. Thank you for your contributions.

HughP commented 4 years ago

@gcushen

What about an approach like this:

allow the end user to define any schema.org attribute they want in the header and include that in the JSON+LD payload?

It might work like this:

schema_copyrightHolder = "Hugh Paterson III"
schema_isPartOf ""
schema_xsomeproperty

Then "scoop" all values of properties which start with schema_ package those into the payload. There might be better ways to guarantee exactly accurate information, but this would give end users a great deal of power.

I'm not sure how we might mark up something like the following:

"copyrightHolder": {
"@type": "Person",
"name": "Hugh Paterson III"
}