I want to completely run my calendar from my website, even if it's just as a series of RSVPs. I think tomorrow at HWC I'll scope out exactly what I do for this to happen. Off the top of my head, I need:
+ https://developers.google.com/web/updates/2015/03/push-notificatons-on-the-open-web?hl=en
Amy added https://developers.google.com/web/updates/2015/03/push-notificatons-on-the-open-web?hl=en to https://rhiaro.co.uk/bookmarks/
This weekend at IndieWebCamp in Brighton, my main goal is to display received webmentions on my posts. Currently I collect them at webmention.io and will occasionally manually add them to my store when there's a reply I'd particularly like displayed. This is just displayed as a link at the bottom of the post.
Initially I thought about just running a cron job to pull from webmention.io into my store. Since webmention.io does all the validating etc, this takes away a lot of work. Maybe I'll do that first, and sort out the display of full comments (not just URLs), and then look at dealing with the whole process myself. Here's the expected flow:
// If target not exists
// Fail
// else If source not exists (404 or 410)
// If have had webmention from this source before OR have mentioned this post myself
// Delete
// -> Remove $source from local store
// else
// Fail
// else If source not contains link to target
// Fail
//
// else If have had webmention from this source before
// This is an update: what has changed?
// Content - edit "$source-author edited their {inferred post type} of/to $target"
// -> Store updated $source for display
// {property} - edit or addition of property "$source-author edited/added {property} of their {inferred post type} of/to $target"
// -> If this is a property I store/display, store update
// Replies/comments - new reply (receiving salmention) "$reply-author {inferred post type}d $source-author's post that mentions $target"
// -> Store for future threading display purposes..
//
// else Infer mention type
// Content - mention "$source-author mentioned $target in a post."
// like-of - like "$source-author liked $target"
// repost-of - repost "$source-author reposted $target"
// bookmark-of - bookmark "$source-author bookmarked $target"
// category - tag "$source-author tagged $target in a post" / "$source-author tagged a post with $target"
// in-reply-to - reply "$source-author replied to $target"
// {other property} - {other} "$source-author {other}-ed $target"
// -> Store necessary $source contents for display
// -> Resend webmentions to all links in $target (send salmention)Once automatic display is working, one way or another, I'll also:
Other things I might get around to this weekend:
+ https://gist.github.com/aaronpk/40d6bb333447ff4265a4
Amy added https://gist.github.com/aaronpk/40d6bb333447ff4265a4 to https://rhiaro.co.uk/bookmarks/
I finally moved Slog'd issues from my head+Workflowy+indiewebcamp wiki to actual issues on bitbucket!
CLEAR YOUR CACHES EVERYONE, NEW WEBSITE IS UP.
Whew.
If micropub used JSON instead of (/as well as) form encoding, what might submissions look like? Aaaron Parecki brainstormed about this on our Social APIs brainstorming doc. I'm going to repeat his examples for create/update/delete here, compare them with equivalent AS2.0 json, then explore other post 'types'.
Note: I've left out @context from all AS examples because we agreed when missing, this is implied to be "https://www.w3.org/ns/activitystreams".
{
"object": {
"content": "hello world",
"category": ["indieweb"],
"published": "2015-05-15T13:06:00+02:00",
"author": "https://rhiaro.co.uk/about#me"
}
}No URL is given so it's implied that a new post is being created. Most of this is Aaron's example but I added the explicit published date and author, but these could also be added automatically by the micropub endpoint as the current time and the authenticated user who is sending the request.
ISSUE: actor vs author may never get agreed upon. I think actor is too abstract and author is too specific. I'm a fan of agent to mean 'whatever caused this to happen' (be it human, group, process or bot) but I know that's not an easy sell either. I think one side is going to have to suck it up, and I don't know who this is going to be. AS also has attributedTo which may be a reasonable compromise but seems a bit clunky.
Response per micropub spec: 201 Created and the URL of the post in the Location header.
An AS2.0 Activity for creating a new post would look like:
{
"@type": "Post",
"published": "2015-05-15T13:06:00+02:00",
"actor": "https://rhiaro.co.uk/about#me",
"object": {
"content": "hello world",
"category": ["indieweb"]
}
}Response per ActivityPump spec: "This has the side effect that of the object that they are posting is being created." - either I missed something more specific in the spec or this remains to be clarified (I'm not criticising, AP is very much under-development!).
I prefer the first one. Key differences:
type on the activity (whereas Post or Create is implied in the micropub example).published and actor) are attached to the activity, not the object.There has been a bit of discussion about whether things like audience targeting (to) would be better off attached to the object rather than the activity; I'm inclined to think there's no metadata related to the creating of an object that can't/shouldn't be attached to the object itself, rendering the activity redundant. I keep asking people of examples that contradict this, but so far nobody has given me one.
Aaron's micropub example:
{
"url": "http://example.com/post/1",
"object": {
"content": "hello moon"
}
}ActivityStreams:
{
"@type": "Update",
"object": "http://example.org/post/1"
}But the latter doesn't contain the updates made to the object... I might be missing something, but there are no specifics in the ActivityPump spec about this; presumably the user updates the object directly and the Update activity is generated from that, which is a curiously object-centric happening in an activity-centric world. Neither contain the updated date; presumably for micropub the endpoint is expected to fill this gap automatically, and possibly in the AS example the activity is meant to have a published property which could also automatically be filled in by the server. I'd like to be explicit about the updated date, though I don't know if this is a must or a should or a may. An alternative I like is:
{
"object": {
"@id": "http://example.org/post/1",
"updated": "2015-05-23T15:00:00+02:00",
"content": "hello moon"
}
}id is on the object as in AS, rather than outside it as in micropub, so what you're sending is just the object.type) because an object with an id was supplied.content is submitted, which will replace what exists.updated date is explicit.ISSUE: I feel like persuading microformats afficondos to use @id instead of url might be a toughie.
Aaron's example:
{
"url": "http://example.com/post/1",
"action": "delete"
}ActivityStreams:
{
"@type": "Delete",
"object": "http://example.org/post/1"
}They look pleasantly similar :) ActivityPump specifies that "this must leave a shell of the object that will be displayed in activities which reference the deleted object. If the deleted object is requested the server should respond with the HTTP 410 Gone status code."
The empty 'shell' with the deleted date is useful if you want to preserve when you deleted things. Discussed this in #indiewebcamp IRC a bit, and tantek suggested that emptying a post of all metadata but the updated property would suffice for implying a delete. An alternative to the examples above could be:
{
"object": {
"@id": "http://example.org/post/1",
"updated": "2015-05-23T15:00:00+:02:00",
"...": "...."
}
}where "...": "..." means... well, we need to define update behaviour before we can define delete-via-update behaviour. If omitting properties during an update removes them, then we don't need to send empty values for a delete. But if partial updates work, and the properties you send are changed and all others remain the same (which I think is better) then we need to send empty values for everything to delete them. This also allows the possibility of replacing content with say "This post has been deleted" or "this post was removed due to its offensive nature" or "I spelt literally every word wrong and it seemed easier just to forget about it" and so on, which could be useful for smarter display of deleted posts (ie. as normal posts that have been updated to say they've been deleted). I'm sure someone will have something to say about the semantics of delete vs update; if so, please back it up with practical examples/use cases :)
We also need to consider that someone deleting a post may not want to leave a trace, even if just an updated date and simply return a 410 if someone tries to access. This should be allowed, with the caveat that it's not possible to advise other servers that may have consumed the post that it's gone if they don't actively try to retrieve it and see the 410.
Or posting a like. Depending on whether you have object- or activity-tinted glasses. New grounds, so I'll start with what exists in ActivityStreams:
{
"@type": "Like",
"published": "2015-05-15T13:06:00+02:00",
"actor": "https://rhiaro.co.uk/about#me",
"object": "https://theperplexingpariah.co.uk/2015/05/a-post",
}Remember in microformats we have the like-of property which would have the same value as object does above, this time, and the 'like' is a first-class post object in itself. So submitting one via micropub could look like:
{
"object": {
"published": "2015-05-15T13:06:00+02:00",
"author": "https://rhiaro.co.uk/about#me"
"like-of": "https://theperplexingpariah.co.uk/2015/05/a-post"
}
}These are preeetttty different with regards to how terms are being used. A more AS-friendly version where the like is still treated as a first-class object would be:
{
"@type": "Like",
"published": "2015-05-15T13:06:00+02:00",
"actor": "https://rhiaro.co.uk/about#me",
"object": "https://theperplexingpariah.co.uk/2015/05/a-post",
"result": {
"published": "2015-05-15T13:06:00+02:00",
"author": "https://rhiaro.co.uk/about#me"
}
}Even though a like post is implicitly created through the result you have to go via the activity that generated it to find out what it's a like of so it doesn't really stand on its own. In the same way as audience targeting and other metadata is useful attached to the object I think having the like relation directly between the objects is practical. For semantic pedants, one post is a like-of another post, so it's closer to having a like type than being a like verb. But it's an implicit type, rather than an explicit one. Just to reiterate: I'm not saying 'post A likes post B'. That would be silly. 'Post A like-of post B' pretty easily implies the author of post A likes post B. It's not worth trying to overthink that, and you don't need RDF inferencing to make sense of it.
In summary, even for things other than creating posts, I think just sending an object works. You can attach other things like "content": "I like Jessica's post" too if you wanted, for nicer display.
The closest example in ActivityStreams is an Arrive activity:
{
"@context": "https://www.w3.org/ns/activitystreams",
"@type": "Arrive",
"actor": {
"@type": "Person",
"displayName": "Sally"
},
"location": {
"@type": "Place",
"displayName": "Work"
},
"origin": {
"@type": "Place",
"displayName": "Home"
}
}I have never needed origin with a checkin so I'm going to ignore that for now. I think I want to send to my micropub endpoint something more like:
{
"object": {
"published": "2015-05-23T13:00:00+02:00",
"location": "https://rhiaro.co.uk/home",
"content": "I got home"
}
}or
{
"object": {
"published": "2015-05-23T13:00:00+02:00",
"location": "http://dbpedia.org/resource/Edinburgh",
"content": "Finally back in Auld Reekie!"
}
}These are just like regular posts, but with a location property. Which is magically compatible with ActivityStremas and Microformats!
Where location is always a URI, so that display name, latitude, longitude, etc, can be attached to that and don't need to be included in the checkin. I'm a big fan of not nesting. If you submit a checkin with a nested venue object, the endpoint has to try to create the venue before it can do the checkin, which means it needs to attempt to de-dup venues as part of the checkin process; and if the creation fails then there's more hassle... there's probably a smart way of designing the UI plus use of javascript that can make this pretty smooth, but it's definitely not something I want to have to deal with.
In AS we have Accept which is supposed to have an object of Invite which in turn has an object of Event (whether these are all nested in the Accept activity or just referenced by URI doesn't really matter, the structure is the same. I included the nesting here cos I just copied the example directly from the AS vocabulary spec):
{
"@context": "https://www.w3.org/ns/activitystreams",
"@type": "Accept",
"actor": {
"@type": "Person",
"displayName": "Sally"
},
"object": {
"@type": "Invite",
"actor": "http://john.example.org",
"object": {
"@type": "Event",
"displayName": "A Party!"
}
}
}While it's all semantically-pedantically very lovely, I reckon the microformats way of just having an RSVP be a regular post with a reply-to another regular post which happens to have a location, start and end (thus making it an event) is easier to follow and generally simpler (and effective as evidenced by all the people posting and RSVPing to indie events). In JSON, I think that'd look like:
{
"object": {
"published: "2015-05-23T13:00:00+02:00",
"reply-to": "http://indiewebcamp.com/2015/Edinburgh",
"rsvp": "Yes",
"content": "Really looking forward to IWC Edinburgh!"
}
}Microformats does have invitations too though - what's the fun of RSVPing to an event if you can't invite your friends! Invite posts can be part of an event post, part of an RSVP post, or a post by themselves. That's because all we're really doing to create them is adding invitee properties for everyone you want to invite, and then sending them webmentions. If your invitation is not also the original event, you can send the original event post a webmention too (since you've mentioned it, after all) which could allow it to update its own list of who has been invited. Your invitee should reply with their RSVP both to your invitation and the event (which they can do with one post). Brainstorming about this, which is by no means sent in stone, on IWC wiki.
Here is an event with a list of invitees:
{
"object": {
"published: "2015-05-23T13:00:00+02:00",
"name": "IndieWebCamp Edinburgh",
"start": "2015-07-25T10:00:00+01:00"
"end": "2015-07-26T18:00:00+01:00",
"location": "http://dbpedia.org/resource/Edinburgh",
"content": "Bring your friends to IWC Edinburgh!",
"invitee": ["http://tantek.com", "http://theperplexingpariah.co.uk", "http://aaronpk.com"]
}
}Neither ActivityStreams nor Micorformats have things to do with eating and drinking, but this is something I log on my site. My micropub endpoint currently recognises Aaron's p3k-food property so I'll use that here, but I'd prefer it to be something more generic..
{
"object": {
"published": "2015-05-23T17:00:00+02:00",
"p3k-food": "A burrito",
"category": ["mexican","burrito","yum"]
}
}A potentially useful fall back for something that wants to display this post but doesn't understand p3k-food could just to be to treat it as content.
Yes, I do desire to tag my food posts.
The value of p3k-food could also be a handy URI for the food, if one existed, which when dereferenced could give you things like different language display names, calorie count, cuisine affiliations, ingredients, etc.
My micropub endpoint will accept JSON and expect an object with a bunch of properties. From these properties my server can infer how to treat them with regards to who to send webmentions to (ie. who to explicitly notify that this object was created; if I was implementing ActivityPump I'd send the whole object to these people's inboxes) and how to display them. It dosen't need explicit types, or properties spread over activities and objects to do this.
In anther post I'll run through this for (un)follows, adding to and removing from collections, exercise posts, music listens, code commits, travel plans, offers and requests, and see if they hold up the same.
If you have examples of online social stuff you do that you don't think you could publish and propagate this way, please tell me all about it. I really want to know.
USB copy php files onto phone, upload with AndFTP. Development on train with no tether 3g contract has never been easier!
Render reposts of tweets properly
If you've been paying attention to me IRL or in IRC lately, you'll have had me try to persuade you that activities and posts are basically the same thing. People advocating post-centric views and people advocating activity-centric views are really describing the same thing from different angles, and with slightly different data models.
An activity looks generally like:
And a post looks generally like:
Colour coding indicates what correlates between the two. Differences:
| Activity | Post | |
|---|---|---|
| type | explicit | implied by properties |
| relationship to another object | object |
value of arbitrary property |
| meta | some on activity, some on result |
all on post |
But you can see that the data they contain are basically the same. Bear with me.
To propagate changes through a network. To tell people that somebody did something.
Posts are content, an end in themselves.
As someone who just wants to publish stuff and interact on the web, do I care if I'm creating and pushing around posts, or activities? Probably not. I just want to do stuff, and have people see it.
As a developer, I want to post objects around that contain as much data as needed, and no more. I want the right people to know when something has changed. Whether I prefer to do this with activities or posts (or JSON or HTML) is, as far as I see it, personal preference. I don't think there's an inherant advantage to one over the other.
Starting with a blog perspective, the most important thing is that people see my content. Posts are my content, so I start there.
For humans, the posts are displayed in html, and for machines they're marked up with minimal microformats, which allows a reader such as Woodwind to parse out the relevant information and display however necessary. (Mine are also avaiable as RDF, but to the best of my knowledge nobody has built a blog reader that consumes RDF yet).
In the ActivityStreams model, rather than creating posts directly, the user performs some activity which may generate as a side-effect a post. The activty could be something like Post, Share, Like (with many other terms currently in the vocab), with an optional target of an object being acted upon, and an optional result of a new object being created. Upon creation, the activity is sent by the server to the servers of anyone who is expected to receive it - either a default list such as people who have subscribed to the author, or a specific list of other people specified when the activity is created, or anyone mentioned or replied-to etc. Anyone for whom the activity ends up on their inbox might get a notification, and their server can fetch the associated post for them.
Not all activities generate a result post and some activities generate a result that is the same as the object. In these cases, I would argue that an activity == a post...
Currently, when I like something I create a like post, that looks like this:
A like activity looks like this:
See how similar they are?!
So given this apparent direct mapping between posts and activities...
Dreaming of interoperability with ActivityPump implementations, I want to generate AS2.0 compliant activities that I can send out. I stuck to super basic representations for now, nesting as little as possible (figuring everything with a URI can be dereferenced anyway, so all of the data doesn't need to be present in the first layer of JSON).
So for a new post such as:
<article class="h-entry">
<h1 class="p-name">Post title</h1>
<div class="e-content">
<p>This is a post!</p>
</div>
<time class="dt-published" datetime="2015-05-15T13:06:00+02:00"><a href="https://rhiaro.co.uk/2015/05/a-post" class="u-url u-uid">15th May 2015 13:06</a></time>
<p class="h-card p-author p-name"><a href="https://rhiaro.co.uk/about#me" class="u-url">Amy Guy</a></p>
</article>The activity generated looks like:
{
"@type": "Post",
"published": "2015-05-15T13:06:00+02:00",
"actor": "https://rhiaro.co.uk/about#me",
"object": "https://rhiaro.co.uk/2015/05/a-post",
"result": {
"@id": "https://rhiaro.co.uk/2015/05/a-post"
}
}With no explicit audience specified, an ActivityPump compliant server would post this to the inboxes of all of my followers. Their server would see the new activity and insert it into their feed; they could click it and view the object (the post). Note that the object of the activity and the result here are the same, so there's some redundancy.
For a like post - because I start with posts, I keep the result of the activity as the like post and retain this redundancy, though this isn't necessary and (see diagram above) you could in fact consider the activity to be equivalent to the like post, and use the ID of the activity to interact with it (if someone wanted to like my like, etc). I have no explicit post types, so it's implicitly considerd a 'like' post due to the like-of microformats property:
<article class="h-entry">
<p class="p-name e-content">I like <a href="https://theperplexingpariah.co.uk/2015/05/a-post" class="u-like-of">Jessica's post</a>.</p>
<time class="dt-published" datetime="2015-05-15T13:06:00+02:00"><a href="https://rhiaro.co.uk/2015/05/a-like" class="u-url u-uid">15th May 2015 13:06</a></time>
<p class="h-card p-author p-name"><a href="https://rhiaro.co.uk/about#me" class="u-url">Amy Guy</a></p>
</article>And the activity:
{
"@type": "Like",
"published": "2015-05-15T13:06:00+02:00",
"actor": "https://rhiaro.co.uk/about#me",
"object": "https://theperplexingpariah.co.uk/2015/05/a-post",
"result": {
"@id": "https://rhiaro.co.uk/2015/05/a-like"
}
}In this case, as well as any explicit or default audience specified, my server would post this activity to Jessica's inbox, whether Jessica is following me or not, as it's a like of her post. Her server can notify her, insert this into her feed, and it's also her server's job to send this activity out to everyone (probably Jessica's followers) who recieved the original post (the one I'm liking), so the 'like' counter can be incremented consistently for everyone, whether they know you or not.
Without activities (my current setup), I'd send a webmention to Jessica, and there's nothing specified about how her server should handle this (beyond checking it's valid), so propagating the like out to everyone who had seen her post wouldn't necessarily happen. However, she is likely to display the number of 'likes' on her post, so a reader could pull the new number of likes each time anyone viewed it (or poll continuously if it wanted a live-update), which puts a lot of burden on the client rather than the server.
So I generate activities like this for all of my posts so far. As I removed all explicit post types from my storage, I rely only on the properties of a post to decide how to display it. I implemented similar rules to generate the activity types required by AS2.0. These rules cascade:
name exists (object has a title) -> Postlocation exists -> Arrivelike-of exists -> Likebookmark-of exists -> Saverepost-of exists -> SharePostin-reply-to exists and has category "rsvp" -> Accept
RespondI also check nameless posts for eat and sleep tags, as these indicate a lifelog post for eating or sleeping, and use types _:Consume and _:Sleep (my own namespace, as AS2.0 doesn't have these types. TODO: Reuse an existing vocab for these). I'll be adding running, yoga, hiking, listening to music and committing code imminantly, so I might need more activity types. I probably need to model these better than relying on tags (but... maybe not. We'll see).
If you noticed that the object of a Consume activity is a blog post, you're a semantic pedant, and you're right, this doesn't make sense. The next best option given the data I currently store is the object being blank node with a label of the contents of the post, eg:
{
"@type": "Consume",
"published": "2015-05-15T13:06:00+02:00",
"actor": "https://rhiaro.co.uk/about#me",
"object": {
"title": "An apple"
},
"result": {
"@id": "https://rhiaro.co.uk/2015/05/a-nom"
}
}But ideally the object would have it's own URI. This probably isn't something I'm going to do any time soon.
Note an object (a post) is still created as a result of the Consume activity. This isn't necessary - as with likes, the pure activity could be sent and displayed to people - but since I start with posts, I wouldn't drop them.
If you're squinting at my location -> Arrive rule, note my own special rules for displaying checkins. This is subject to change.
Sometimes, when you want to do something on the web, it doesn't feel like making a post. For example, if I want to delete a blog post, I need to tell everyone who received it that it's deleted. In indiewebland, you just delete the post, return a 410, and send a webmention to anyone who needs it. However, this doesn't leave any record of when it was deleted (or when it was created). You might have noticed I like tracking everything, so the ActivityPump way of deleting - which retains a trace of the deletion - appeals to me:
{
"@type": "Delete",
"@id": "https://rhiaro.co.uk/2015/05/delete-bad-post",
"published": "2015-05-15T13:06:00+02:00",
"actor": "https://rhiaro.co.uk/about#me",
"object": "https://rhiaro.co.uk/2015/05/bad-post",
"result": {
"@id": "https://rhiaro.co.uk/2015/05/bad-post",
"deleted": "2015-05-15T13:06:00+02:00"
}
}(In the current ActivityPump spec, the result is a shell of the object that is being deleted, so the URI of the deleted post is retained with a deletion date attached, but all other properties deleted).
But when you think about deleting a post, you're not thinking about creating a delete post which references the post you want to delete (if this is how you think about it, I'd love to hear from you). You want to hit delete, and have everyone suitably notified. The same for updates/edits/modifications (of your own post - creating a diff post as an edit to somene else's post or a wiki page is a different matter).
Nonetheless, if I wanted to display the delete activity for humans, I could mark it up in HTML with microformats, just as if it were a post, something like:
<article class="h-entry">
<p class="p-name e-content">I deleted <a href="https://rhiaro.co.uk/2015/05/bad-post" class="u-delete-of">a post</a>.</p>
<time class="dt-published" datetime="2015-05-15T13:06:00+02:00"><a href="https://rhiaro.co.uk/2015/05/delete-bad-post" class="u-url u-uid">15th May 2015 13:06</a></time>
<p class="h-card p-author p-name"><a href="https://rhiaro.co.uk/about#me" class="u-url">Amy Guy</a></p>
</article>Note:
u-delete-of, this doesn't currently exist.content (or existing displayName) property on the activity could be used for this. Where this content comes from could be implementation-dependant, with some sensible default fallback.So even though they're basically the same thinking about 'delete' as an activity rather than a post feels easier and it is still possible to treat as a post for display if you need to.
At the moment I store a modified date and just update this whenever I edit a post. For now I plan to add something that checks all posts for a updated date and slots Update activities into the stream (even though there is no explicit update-of post). When I can update posts properly with micropub, I will generate the update activity then.
There are other activities ((un)follow/add/remove/join/leave) that I also think would be simpler to think of in this way. I don't currently know of anyone in indieweb who is displaying posts for these marked up with microformats, though I have a couple of experimantal follows posts with u-follow-of.
Once I have AS2.0 compliant activities, I could post them to inboxes of [ActivityPump]() compliant servers. Someone should implement one please :)
Certain activities (like Follow) may trigger special side-effects (a user is added to another users followers collection according to pump.io and ActivityPump (not ActivityStreams)). In indieweb, if you want to follow someone you type their URL into a reader and it fetches their content. What's missing is the reader being able to post a follow activity to your site via micropub so that others (including who you have just followed) can be notified of your follow, and if you have a public list of follows, that can be updated too.
This is out of scope for this post, but I think core side-effects like this need to be clearly defined, and we also need a clear way of defining new side-effects as extensions.
I picked Innsbruck pretty randomly as a mid-point between Dusseldorf (where I was for IWC) and Florence (where I need to be for WWW). I haven't been to Austria before, or even the Alps bar a day-trip during a school trip to France like ten years ago. The first day I was here was clear, sunny and crazy hot, so I started loving Innsbruck pretty immediately. I wandered around town, got a feel for the place, and found the only place I could get vegan pizza and eiskaffee.
The Inn river is fast-flowing and a cartoonish blue-green. The houses are bright colours, and everywhere is walkable. The town is surrounded by a ring of snow-capped mountains.
I booked a hostel so I wouldn't have to socialise too much, as I need a break from people between all of these conferences. The hostel is super quiet, and mostly pretty good. The first night I shared my dorm with two Canadian girls. They told me the funicular up one of the mountains is reasonably priced, and that it was silly to think of walking to the base as it's really far, and I should get the bus. Also that I should pay the EUR 2.60 for a bus ticket, as one of them didn't and got caught and fined ;)
Yesterday I hacked a bunch on Slog'd in the morning, then at 2pm set off with vague intentions of either climbing a mountain or swimming in a lake, ideally both. I ignored the advice of the Canadian girls, and walked to Hungerburg where the cable car starts. It was less than an hour from the hostel, and the mountain parts were easy. Turns out the cable car to the top is over 25 EUR, and it's about a 3 hour climb to Seegrube. And climbing is WAY more interesting. However, from Seegrube to the summit at Halekefar I was advised there is too much snow for climbing, so the cable car for that stretch is mandatory (and Seegrube-Halekefar is EUR 6.10 return, which I can handle). So I figured I'd climb to Seegrube, take the cable car to the summit and back, and climb all the way back on foot. But by that point, the odds of me making it to Seegrube before the cablecar stopped running at 1730 were pretty slim. I toyed with trying to find an ATM and taking the cablecar all the way, but decided I'd prefer to climb anyway and can come back the next day, earlier.
Then I walked to Lake Rossau, which the internet claims cost EUR 3.50 to swim in but I mean, it's a lake, so nobody seemed to be enforcing this. So I swam in the lake surrounded by mountains and it was beautiful.
Then I came back to the hostel and added a first pass at ActivityStreams2.0 JSON to my site. Woo! Productive day.
Today it is raining heavily and the mountains are shrouded in clouds. Naturally. Turns out I'm going to give getting to Halekefar a shot anyway, even if I can't see anything from the top, thanks to encouragement from my new hostel roomie, a fairly old Vietnamese lady who lives in Belgium.
Also, I'll post some photos just as soon as I implement display of albums and attaching Collections to posts on Slog'd.... Aaaaany day now.
When is it a checkin (with a note) and when is it a note (with a location)? Hot topic. I differentiate them for display purposes (currently I just show a map-marker icon next to checkins, but I'm also going to want to show them on a map and stuff).
For now, my rule is:
location property, which should be a URL of a place (venue/city/country/vague), it's a checkin.
latitude and longitude (my vague checkins, eg. 'home', do not).content.latitude and longitude and no location, it's a note with a location.
My inner semantic pedant is unhappy with attaching a lat and lon to a post directly, so I might rethink this at some point.
I'm supposed to be working, so instead I'm making a list of wee annoying bugs in Slog'd that I could and should fix fairly easily this weekend:
Aaaaas usual it's my code, not someone else's, that is causing my problems. Hashtag interop.
So SPARQL DESCRIBE queries are literally 8x slower than an equivalent CONSTRUCT { ?s ?p ?o . }. Who knew? Not me. Maybe this isn't news to anyone who knows anything about graphs and/or query languages.
Live demo'd my blog sparql endpoint at the pub, pretty sure I'm the coolest