Getting from schema.org to a concept model and data schemas about modelling-opportunity-data HOT 5 CLOSED

@MikeThacker1 I might be misunderstanding you, but why don't the Schema.org types and properties give us that model?

We can use the Schema.org model to publish data structured as JSON-LD. And this also gives us an RDF interpretation and cross-walk to other formats. This gives us a way to publish and embed data in web pages, and also via (JSON) APIs

After getting some agreement with the model outlined in this document, I was also going to recommend some simple CSV format(s) for publishing the data. CSV on the Web can then map that to the Schema.org model?

from modelling-opportunity-data.

Thanks Leigh. The schema types and properties may give us that model. I'm used to dealing with UML class diagrams or data entity relation diagrams. What I can't see here is how we get the cardinality rules (eg one event must have one and only one location; it can have one or many startDates; OR one event can have multiple combinations of location and startDate; it can relate to 0, 1 or many types of PhysicalActivity; ...).

The JSON-LD might make it clear - especially if that can be converted to a diagrammatic representation.

Sorry if I'm misunderstanding anything. I'm trying to relate this to the approach taken by another project I'm involved in.

from modelling-opportunity-data.

Ah ok, I see what you mean. My plan is, if people are happy with the model and mapping, then to define some conformance criteria that can be used to say things like "this must have a location", etc. That would cover what you're looking for I think.

But you're right that a diagram would be useful too. I'll add one to the specification.

from modelling-opportunity-data.

I'll incorporate this into the specification after I've had comments next week, but here's a initial schema diagram that shows the relationships between the items.

The Activity/Programme stuff is still to be decided, but included for reference for now.

from modelling-opportunity-data.

Thanks Leigh. Looks good and helps me. It's simpler than I expected.

As a minor point, I guess Event should have two joins on itself to deal with subEvent and superEvent relationships. Not sure how recurring events would complicate it.

from modelling-opportunity-data.