You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While we were importing parliamentary data from local governments (municipalities from the Netherlands) and national governments (e.g. the Dutch parliament), we found that governments tend to structure their meetings with agenda items. The meeting software that they use also structures the various themes and issues in this way.
Currently, the popolo specification lets events have child events. Therefore, we should store these items as 'events'.
However, this poses a problem. Say, for example, that a web application wants to render a calendar that displays all meetings for some government. It fetches all events, but this also includes the children of events. This creates multiple events for a single point in time (one parent + all sub-events), where people are present at both.
I suggest that we introduce a new schema for these sub-event children: Agenda Items. I suggest that its schema inherits schema:CreativeWork consists of the following attributes:
An array of attachments (I don't know what's the best schema for this, but as a client I'd like to be able to see the URI of the attachment, its title, its data type and its size)
An array of motions (items on which can be decided and or voted)
A parent event URI (required)
An index integer which represents the position in the array of agenda items (required)
What are your thoughts on this?
The text was updated successfully, but these errors were encountered:
While we were importing parliamentary data from local governments (municipalities from the Netherlands) and national governments (e.g. the Dutch parliament), we found that governments tend to structure their meetings with agenda items. The meeting software that they use also structures the various themes and issues in this way.
Currently, the popolo specification lets events have child events. Therefore, we should store these items as 'events'.
However, this poses a problem. Say, for example, that a web application wants to render a calendar that displays all meetings for some government. It fetches all events, but this also includes the children of events. This creates multiple events for a single point in time (one parent + all sub-events), where people are present at both.
I suggest that we introduce a new schema for these sub-event children: Agenda Items. I suggest that its schema inherits schema:CreativeWork consists of the following attributes:
What are your thoughts on this?
The text was updated successfully, but these errors were encountered: