Skip to content


Feedback on Election Vocabulary

A peer on twitter asked for feedback on this vocabulary of terms to describe an election. I thought it might be helpful to make as a public post. No disrespect is intended and my views about vocab. design may not be in line with everybody elses. If I’m wrong; leave a comment!

[update: It seems this wasn’t the final version but a preview for me to review, so apologies if I gave the impression this was the official release]

http://linkedopendatang.com/schemas/election/v2/linkedopenelection.ttl

First of all, before I get nit-picky, this isn’t a disaster. It will solve an immediate need but there’s plenty of ways to make it more useful and reusable.

Validation

First of all it’s not a valid file! Always use a validator to check your RDF, and I generally recommend using a library to produce it. In fact a full validation chain would be:

  • Check the file can parse using a basic validator
  • Check for silly mistakes and typos using triple checker
  • Check for logical errors using an appropriate tool, eg. make sure it’s not got logical impossibilities.

rdfs:label

This vocabulary has very lasy choices for rdfs:label — these should be human-readable terms that make sense when said out loud. It almost never makes things better to prefix all the predicate labels with “has”. I get the impression that this vocab. is intended to describe primarily African elections and would be inclined to make the labels clearly specified as being in @en to make it easier to add translations later.

Too specific definitions

I would start by thinking about the most generic concepts for what an election is; it’s a vote where some or all of a pool of eligible voters register their choice(s) in a timeframe between two or more options. The options may be people to gain a political office, but that’s a special case. Multiple things may be decided during the same process, eg. voting for mayor and chief of police. In some voting systems people may vote for multiple candidates or rank their preferences. I see that the vocab. seems to also have the idea of candidates voting for bills and this should be the same basic concepts. Also, there’s no reason to restrict candidates to be foaf:Person– I believe that it’s quite common for inflatable bananas and bottles of beer to stand for election in student unions… possibly candidates could be considered foaf:Agent… and voters definitely can, but a set of internet-of-things devices or intelligent-agent-softwares can hold elections — no humans invovled.

Again, PollingBooth is very specific. I would suggest something more generic such as polling location or even polling node (not all polling booths will have meaningful real-world locations as things become more digital, but they still represent a collection of eligable voters and their resulting votes.)

A slight other nitpick is that I would have an Election be a subclass of a poll and have candidates be candidates for election to a role. A poll could be a broader question such as should we allow shops to trade on Sunday, or the recent vote on if Scotland should remain part of the UK.

Inconsistent approaches

The vocabulary contains both these terms election:hasConstituencyLat_Long and election:hasGeoLatitude. This is pretty muddled. It’s increasing the tasks for anybody parsing the data as they now have to cope with both a combined lat long type and a comma-separated one. I’d go with the separated one for both cases and just use geo:lat.

Reinventing wheels

This vocabulary has a number of very appropriate specific terms like Political Party and Candidate. Those belong as they add real value and indicate what terms you might reasonably expect associated with those entities.

However there’s terms which are just duplicates of existing well established terms and I would prefer to just use those existing terms. That way data tools which understand those terms will understand the data without any extra work.

The social media section terms can be easily replaced with FOAF equivalents.

election:hasDate is a subproperty of dc:date, and this one I’m a bit torn on as it does give a more specific meaning so I’ll allow it, but it should be datePromised not just hasDate to gain that value.

election:hasGeoLatitude and the other lat/long terms would be better replaced with geo:lat and geo:long.

hasURL might as well just be foaf:page unless there’s value to add and “hasURL” adds no more specific meaning.

election:image is nearly appropriate because it’s more specific than foaf:depiction as it’s a depiction of someone relating to a specific election, not any time in their life… However that still requires an explicit link between the image and the election. Imagine you compile RDF from three elections and the same candidate stood in all three. How would you detect which depiction is associated with that candidate in a specific election? This needs a bit of work.

Multiple elections

This leads me into a core issue. There’s a statement that the candidate is a person, and that they have a name, get votes etc. I think this is a mistake and a small tweak is required. I suggest that the person and their candidacy are different entities. One person may *be* a candidate, but their candidancy relates them to a single election with a result. Things like their image and their name may be more useful to link to their candidacy. For example Miss Gemma Smith may have run in the 2001 election, and lost and then after marriage Mrs Gemma Jones (same person) won in 2005. Both names are true for the foaf:Person but the candidacy has a speicific name for that elelction!

3 State Logic

There are some terms which capture if an official voted ‘yes’ or ‘no’ on an issue or bill. I would be tempted to rename these to “for” and “against. I would also suggest adding in “Formally Abstained” and “Did not vote”. Without logging abstentions there’s no way to tell the difference between “no data” and “abstained”. My suggestion of the “formally abstained” is to record when someone actively abstained, for example in the UK parliament walking through both lobbies in a division is a way to record that you were present but chose not to take a side.

Time sensitive terms

election:hasCounted makes me a bit nervous. It’s a boolean based on has an event occurred. I would be much happier with a timestamp recording when the counting completed. Without it you need to know the time the datafile was generated, and the RDF way of thinking is not to rely on document metadata, everything should be explicit.

The same applies to some of the other boolean terms which indicate an event or process is complete.

Promises…

The section on campaign promises seems out of place. It’s far more subjective than the other parts and likely to spark disagreement. I’d suggest adding some kind of citation to back up these statements, eg. a video, news article or press release.

The fraud and violence terms also are controversial and should require some kind of external justification using sources.

Conclusion

I think this effort is well worth continuing but would like to see it able to be used for all levels of democratic decisions not just first-past-the-post elections. I’ve tried to brain dump everything that might be useful and it’s not meant to detract from the hard work that’s gone into this project.

Posted in Best Practice, RDF.


0 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.



Some HTML is OK

or, reply to this post via trackback.