Amy Guy

Raw Blog

Tuesday, April 29, 2014

On the importance of remoteStorage module reuse

Well, the point of Unhosted modules and being explicit about your data schema in modules is so that other developers can reuse them, to make it possible for users to switch between frontend apps that consume the same kinds of data.

Well, duh*.

But there seem to be loads of people making the same kinds of apps over remoteStorage (mostly todo apps or notetaking kind of things) and making their own modules every time!

If one module doesn't offer everything a dev needs for their new app, they should hook in anyway and extend it with their own module on top. That should be pretty straightforward.

So I love LiteWrite, but for notetaking maybe I need a few more organisational facilities. McNotes looked awesome and I was poised to start using it. Then I saw Laverna offers remoteStorage support and that is pretty much a straight up port of Evernote (but ten times as sexy), with tags and notebooks and everything!

When I switched from Evernote to something to something to Springpad (the ones in between didn't do the job, and I've since forgotten what they were) I had all kinds of mess importing my Evernote data, and a lot of it was done manually due to limitations of the various importers. If I'd actually started storing anything useful in LiteWrite, and wanted to move to McNotes and then to Laverna I would have gone through the exact same process... which is a horrible thought, because that's one of the problems remoteStorage is supposed to solve.

So, please, if you're making an app over remoteStorage, look at the other modules that exist first, and use them. And if you're making a new module, please publish it! Otherwise we're missing a butt-ton of opportunities for giving users choices about their UIs, and for mashing things up in amazing ways.

(On that note, I'm keeping a list of Unhosted mashup ideas).

* Although this is kind of obvious, I explicitly came to this realisation after it occurred to me, when trying to work out how to make schema definitions conform to proper JSON-LD, that you go to all the trouble of defining your data schema in your module, but then there's nothing to stop you just storing any old object. You can validate an object against a schema, but there's nothing to do this by default. So I thought why then do I need to bother with this JSON-LD schema faff if I can just store prefixes at object creation time? Then I remembered other people, and reuse and stuff. It took a surprisingly long time (like an hour of frowning) to get to that though. Especially surprising given that all I've been thinking about this evening is Linked Data. Clearly all this JavaScript is obscuring coherent thought.

Unhosted App Ideas

If people release their models and data schema for remoteStorage apps, we can mash them up with much ease! I'm maintaining a list here of ideas that I may or may not get around to implementing:

  • Notetaking app + bookmarking app = WebClipper functionality and/or annotation of webpages
  • Todo app + calendar app = duh.

Since most of the early Unhosted apps are life-organise-y ones, can we just have a dashboard that combines everything? Can we call it SORT YOUR LIFE OUT?

Monday, April 21, 2014

Ontology of the Feels

I had an idea for a tiny wee project to do with quantified self. More on that later.

Because I'm trying to use linked data for everything, for reasons beyond the scope of this post, the first thing I did was sketch out the data I need to store in a graph structure. I need to record emotions, so I did a quick search for ontologies that represent emotions, figuring psychologists and the like must have been at this for years already.

Sure enough I found a few, but the most convincing one, the HUMAINE Emotion Annotation & Representation Language (EARL) is in XML rather than OWL.

Note: There's apparently a lot of disagreement about terms and stuff in this area. Not something I'm invested in, so I'm just going to roll with this XML.

Yay! Time to convert a well structured and useful dataset into RDF. Always a Good Thing.

EARL comes as many files, and goes beyond what I need. But it's not huge, and with a little effort (and looking some stuff up on Wikipedia) I think I can understand what's going on enough to convert the lot.

There are:

  • Categories (names of emotions)
  • Dimensions (ways of describing intensity, I think)
  • Modality types (the means through which the emotion was expressed, eg. face)
  • Regulation attributes (response to an emotion)
  • Appraisal attributes (a list of other descriptive terms; emotional metadata, if you will)
  • Emotion times (start and end)

Emotional occurrences can have all of the above as properties, as well as probability and intensity. Complex emotional occurrences have times, and contain a minimum of two emotional occurrences with the above properties.

The terms are all taken from various different psychological experiments or schools of thought. There are alternative versions of some of these things from something called AIBO. Arbitrarily I'm ignoring everything prefixed AIBO for now.

I'm going through the files and writing everything relevant out, then drawing it as a graph.

First juncture: do I use all the attributes (like the list of 55 emotions) as properties (as they are demonstrated in the original XML) or use classes? Properties seems messy, and feels less extensible, even though technically I suppose it's not.

Maybe they should be properties. Except the categories, they all (or at least most) have corresponding DBPedia entries that it would be stupid not to take advantage of. But the dimensions, regulation and appraisal might be better suited to being properties, otherwise I'm having pointless identifiers or blank nodes everywhere. And nobody wants that.

I adjusted the Samples thing a bit, mostly to simplify it, and I may have got it wrong, but I think it makes sense.

Then I typed it all into WebProtege. As a result, I think quite a few things are overspecified. What do you think? Check it out:

Tuesday, April 01, 2014


I'm visiting the Information Access research group at the Centrum Wiskunde & Informatica in Amsterdam for a week.

I walked around a bit, and discovered that a lot of roads look like pavements, or pavements don't stop being pavements even when they cross over a junction a car can turn down.

Also I keep looking the wrong way when crossing roads and cycle paths.

Fortunately all of the cars and bikes I've stepped out in front of so far have been going very slowly.

Also I don't know if there's a heatwave or if I'd just acclimatised to Scotland more than I thought. Everyone else is going around wearing coats, but I'm sweltering.

I've been here before in 2008, but only have vague memories of tourist attractions and the city hadn't left a lasting impression on me. Hopefully I can pay more attention this time.

Expect more posts about my research-related adventures soon.

Tuesday, February 25, 2014

Blogging with Linked Data

An update; sort an explanation of why I haven't posted anything recently.

I really want more control over my blog data.

I think Linked Data is great and the only way to make it more useful is to use it more.

I'm sick of Blogger's JavaScript heavy wysiwyg editor that doesn't work properly on low-bandwidth connections, or on my Kindle in emergencies.

I want to author blog posts in markdown, add whatever metadata (like tags) I need, and publish them via whatever means I have to hand. From a browser, from a text editor and command line, from an email, from a tweet?

So I'm working on Slog'd: Semantic Blog from Markdown.

I already wrote a wee Python script to convert my existing Blogger posts to linked data: Blogger2LD. I'm making a web interface for this so you can do yours... and I'll do it for Twitter, too. Then who knows what else will follow.

I'm still twiddling with Slog'd itself - which I'm writing in PHP and storing triples in a MySQL database using the ARC2 library, because I want anyone with any bog-standard shared hosting and no understanding of linked data to be able to use this. You can watch progress on Bitbucket.

I've been blogging every detail as I go along. These are in the posts directory in the Slog'd repo, rather than on here.

Tuesday, February 18, 2014

Paper accepted to WWW

My first paper has been accepted to the SOCM14 workshop at WWW.

That means I get to go to Seoul, South Korea, in April!

I'll post a pre-print at some point.