(start|end)(Date|Place) vs schema.org

[VladimirAlexiev]

jskos has 4 "universal" props:

• startDate: date of birth, creation, or estabishment of the item
• endDate: date of death or dissolution of the item
• startPlace: where a concept started (e.g. place of birth)
• endPlace: where a concept ended (e.g. place of death)

In contrast, schema.org splits those by type:

• startDate, endDate (Event, Role, CreativeWorkSeason, CreativeWorkSeries, DatedMoneySpecification, EducationalOccupationalProgram),
• birthDate, deathDate (Person),
• foundationDate, dissolutionDate (Organization);
• birthPlace, deathPlace (Person),
• foundationLocation, dissolutionLocation (Organization) (https://github.com/schemaorg/schemaorg/issues/302)

I like the simplicity of jskos, but this discrepancy means that:

• jskos often uses schema:startDate/endDate incorrectly (there are very few concepts about events/roles etc, whereas plenty are about persons/orgs)
• jskos cannot map startPlace/endPlace to schema (see #96)

I have proposed making appropriate super-props in schema (https://github.com/schemaorg/schemaorg/issues/2481) but I'm doubtful when this will be done, given that https://github.com/schemaorg/schemaorg/issues/302 is still pending.

Until schema does that, how about mapping them to JSKOS own properties?

[nichtich]

This issue is about the mapping of JSKOS to Schema.org ontology.

jskos often uses schema:startDate/endDate incorrectly

So the data mapped from JSKOS to RDF via context.json is not perfect. Could be fixed by guessing the item type (e.g. Person) and changing properties depending on the type (requires logic not possible to express in context.json).

jskos cannot map startPlace/endPlace to schema

So the data mapped from JSKOS to RDF via context.json is not complete.

Unfortunately ontologies never align perfectly. The proposals to extend Schema.org can help to improve the mapping between JSKOS and RDF/Schema.org.

Until schema does that, how about mapping them to JSKOS own properties?

For startDate/endDate this would mean no data instead of imperfect data. I prefer the latter.

I'll map both startPlace/endPlace to https://schema.org/location this is the best match available in Schema.org.

[VladimirAlexiev]

startDate/endDate ... I prefer imperfect data rather than no data

Agreed. Cheers!