Create JSON schemas for things we describe on the web

[acka47]

• Group profile at http://lobid.org/team
• Person profiles at http://lobid.org/team
• Product profiles at http://lobid.org/team
• slide decks at https://slides.lobid.org
• Projects
• Blog posts at blog.lobid.org and in project blogs
• Articles in journals or edited volumes

[acka47]

@TobiasNx If you are interested in this and don't know what to do next week, you might pick this up, add a description of yourself to examples/person/valid/tb.json and start working on a JSON Schema to validate the person profiles in examples/person/valid/.

[TobiasNx]

Suggestions:

• Instead of colleague i think team would be a good element/knot. Through membership of a team, you could associate colleagues, but as field of its own you need to add new members to every team mate individually as I did with my id to every other member.

• Consistent usage of lobid-organisations for all organisation refrences e.g. in alumni.

Question:

• Should the subschemas be more generic? Since not only persons but other parts of our web-publications could be described?

[dr0i]

What is the status of this? Can we open a PR of the branch to review?

[acka47]

I haven't found the time yet to work on this. Will do later this week hopefully.

[acka47]

I have added entries for each product and project in the examples folder. (More as a note to self), here are some things we will need to clarify, some earlier, some later:

• i18n: Adding the name property for persons and projects/products, I used two different approaches: language maps for products/projects as we want to list German and English names and just a key for persons as we do not intent to add a person's name in different languages. However, this would result in two different schemas for the same property. One way towards a common approach would be to use different files per language (and indicating the file's @language in the context) instead of one file per entry with language maps. Then we wouldn't have to use language maps at all. -> Discuss i18n options #473
• What relations do we need between the different types of resources? Lots of them are straightforward but especially the relations between different projects and products wil need some thought. (In the diagram I used uses, improves & updates but we probably should start with only two broader defined relations. Or we might even makes these relations separate nodes to add more context/descriptions to them. -> Create high-level overview of type relations #444
• Create and use a project-specific JSON-LD context (for now, I have added "@context": "https://schema.org" for most entries which is enough for development. In the end, we will have to take a deeper look and create a application-specific context.) -> Use custom JSON-LD context #472

[acka47]

I addressed the open questions in other issues and created an additional one so that we can close this issue.