ldn (16 out of 26)
- Started basic graph-based access control in sloph.
- Flew back to Sarajevo from London.
- Worked on aleph's v2 API and docs.
- Learnt the basics of Celery.
- Memorised numbers from 1-10 and the general principles of bigger ones in Bosnian.
- Hiked up to Skakavac waterfall.
- Wrote tutorial for a quick and dirty PHP LDN Inbox.
- Went to some showings at the Sarajevo Film Festival.
- Started Star Trek: the original series.
- Validate the notification according to its contents; maybe you want to only accept notifications of a certain
@type, or other specific property-value (predicate-object) combinations. - Validate the notification against a data shape.
- Verify the contents by fetching URLs you find in the notification and checking that data returned from these sources corresponds with statements about them in the notification contents.
- Verify the contents by checking the statements made in the notification against statements from your own (or another trusted) knowledgebase.
- Modify the contents of the notification by adding your own provenance information, such as the date you received it.
- Store the notification contents in a database or triplestore.
- Fire off a push notification to your phone.
- Spent the week in Southampton and one day in Oxford talking about decentralisation, scholarly communication, LinkedResearch, personal data stores and the like with cool people like emax, csarven, bblfish, TimBL, Wendy, Nigel, Ramine, Jun, DDR..
- Imagined eprints as a tiny LDN-powered JS app (ldprints).
- Net magazine issue 296 came out in print.. With an article about Linked Data Notifications!
- Missed a bunch of buses.
- Spent a couple of hours eating great food at the Southbank Center food market, just like summer 2014 weekends. Remembered why I love and hate London.
- Surprise visited my Mum. Now I can tweet again.
- Sarven Capadisli (csarven.ca): works on tooling (dokie.li) to improve decentralised article publishing, annotations and social interactions, and an initiative (linkedresearch.org) to improve openness and access to scholarly communication Web.
- Amy Guy (rhiaro.co.uk): is part-time W3C staff, part-time academic, and part time other things; studying how decentralisation affects people, and working on technology that might do some good in the world.
- Co-chaired the ESWC Enabling Decentralised Scholarly Communication workshop.
- Transcribed a panel about the Future of Proceedings Publication.
- Morally supported the presentation of our LDN article.
- Went to some talks and ate some food and stuff.
- Won the Best Student Paper prize.
- Took the train to Rome for ICWE2017; spent the weekend exploring Rome and eating pizza.
- Finished improving my LDN endpoint so notifications actually go into my triplestore with everything else, albeit into a different graph.
- Contributed a bit to the LDN test suite.
- Updated sloph to display
Addactivities where the objects are many images and the target is a photo album.. and ported all of my recent travel pics to this format. - Finally fixed my Acquire posts so they display photos.
- Made type-based post collections.
- Made progress on between-date summary aggregates (so I can use this for a year in review).
- Started yoga classes at Wholey Wonder.
- Joined a drive to Penang Airport in Bayan Lepas, and back.
- Successfully avoided New Year's Eve celebrations.
- Fixed my extension activities in sloph to match the new AS2 recommendations about
nameandsummary. - Started improving my LDN endpoint so notifications actually go into my triplestore with everything else, into a different graph for moderation.
- Helped prepare stuff for the upcoming WOW workshop and our ESWC Decentralised scholarly comms workshop
- Saw Rogue One.
- Climbed Penang Hill; held a scorpion.
- Visited Gurney Drive and Air Itam, briefly.
- Successfully avoided christmas.
Week in review: 7 - 13 August
DIY LDN Inbox
Linked Data Notifications is a protocol to facilitate sharing and reuse of notifications between different Web applications. It's a W3C Recommendation from the Social Web Working Group, and part of a push to help people own their data and re-decentralise the Web, particularly the Social Web. You can read more about why you might want to care about this here.
For this post, I'm going to jump straight into implementation. I've chosen PHP, without any frameworks, because if you already have a (local or remote) server it should be quick for you to get going with, without needing to set up or configure anything. The "Linked Data" in the name implies involvement of RDF; in fact LDN uses JSON-LD, but I don't presume any existing understanding of these things for this post, I'll just try to introduce the minimum that you need as we go along. (For a nice intro to JSON-LD see Manu's YouTube video JSON-LD Basics.) I am assuming though you have a basic understanding of JSON, and what HTTP Headers are.
LDN is a three part protocol. We expect front-end applications as well as servers to play the roles of senders and consumers of notifications. The third part is receiving. As the human in the mix, you need to tell the applications you use where to send notifications that are meant for you (or your software to pick up), as well as where applications can read them from (in order to display them back to you, or to process them and trigger other tasks to run). This 'where' is your Inbox. Applications might, for example, discover it from your homepage or a social media profile. You should host your Inobx somewhere you trust. Just like with email, some people might want to rent space from a provider, or maybe your workplace or school supplies one to you. At the moment the market for this is.. pretty small. This Web-data-owernship thing is in its early days.
So for the pioneering developers among us, we can write our own, using around 50 lines of quick and dirty PHP.
Part 1: accepting and storing new notifications
For convenience, we're going to set some variables for URL paths we will use regularly:
$base = "https://".$_SERVER['HTTP_HOST']; // Your domain $inboxpath = "inbox"; // The directory where your notification files are stored.
First, your script needs to accept HTTP POST requests containing JSON-LD blobs. We get the data from the php://input path. We also get the request headers. LDN receivers need to support as a bare minimum application/ld+json payloads, so we'll send a 415 if the Content-Type header doesn't match this. We're also going to check the payload parses as JSON since that's an easy way to throw out (with a 400 Bad Request) invalid JSON-LD. If you have a JSON-LD parser handy, you can validate it against that too. I haven't included one here because.. quick and dirty.
Aside: If you do have an RDF parser around, you can accept other RDF serialisations like text/turtle. If you do, you should advertise this with an Accept-Post HTTP header on your Inbox. I use EasyRdf for all of my RDF stuff. If you don't want to include a library there are a few services with APIs you can call, like rdf-translator.
$input = file_get_contents('php://input');
$headers = apache_request_headers();
$data = json_decode($input, true);
if(strpos($headers["Content-Type"], "application/ld+json") === false){
header("HTTP/1.1 415 Unsupported Media Type");
}elseif(!$data){
header("HTTP/1.1 400 Bad Request");
echo "Invalid payload.";
}else{
// Write notification contents to a file
}
The LDN specification says that even if you only accept JSON-LD serialized notifications, you should set the Accept-Post header anyway. You can do this in PHP with header("Accept-Post: application/ld+json"); or an .htaccess file with Header set Accept-Post "application/ld+json".
Once we've determined the payload contents are valid, we should store the notification. This is where you might want to do any or all of the following:
But for now, all we're going to do is dump the contents into a file, update the notification's @id to point to the location we're storing it, and set the HTTP response headers:
// Write notification contents to a file
$filename = $inboxpath."/".date("ymd-His")."_".uniqid().".json";
$data["@id"] = $base."/".$filename;
$json = json_encode($data, JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES);
$h = fopen("../".$filename, 'w');
fwrite($h, $json);
fclose($h);
header("HTTP/1.1 201 Created");
header("Location: ".$base."/".$filename);
Aside: This implementation is super simplistic. The notification may come with an @id already set, or even contain several distinct subjects, pointing to resources somewhere else on the Web. Checking that referenced resources makes the same statements as the notification you received could be good practice for verifying the truth of the notification contents. It may also be set to "@id": "", which is relative to request; it basically means 'this'. You don't need to add your own absolute @id if it's already set; you can consider the URL at which you store the data as a graph URI, which contains statements about other things, but not about itself. Alternatively, you could wrap the notification data in @graph and apply your own @id on the top level.
Since we're storing the notifications as JSON files, you probably want to tell your server to return JSON files with Content-Type: application/ld+json. You can do this by putting the following in a .htaccess file: AddType application/ld+json .json.
Part 2: serving notifications
In order to make your notifications reusable by other applications, you need to expose them to GET requests. Specifically, your Inbox needs to return a blob of JSON-LD which points to a list of the URLs from which the individual notifications can be retrieved. You probably want to put this behind some kind of access control, so that only applications with which you have authenticated can read your notifications. I use IndieAuth as a service.
In this case, the URLs in the list are the files we stored the notification data in. The JSON-LD for an Inbox listing should look like:
{
"@context": "http://www.w3.org/ns/ldp#",
"@id": "",
"@type": "ldp:Container",
"contains": [
{
"@id": "https://example.org/notification1"
},
{
"@id": "https://example.org/notification2"
}
]
}
The listing doesn't need to look identical to this, but it needs to be an equivalent JSON-LD representation. Since there are several ways of presenting the same thing in JSON-LD, you might find you use a serializer that outputs something slightly different. For example, you might see the contains part shortened to: "contains": ["https://example.org/notification1", "https://example.org/notification2"]. You're also likely see the @context appear differently, and prefixes for the properties (keys) might be used. The JSON-LD Playground is a good place to look at different possibilities.
Aside: The "@type": "ldp:Container" is optional for LDN, but it helps other LDP clients understand that they might be able to use your data too.
You could store the Inbox listing in a flat file, and update it every time you receive (or delete) a notification. However, for this implementation we're going to generate it dynamically from the JSON files in our "inbox" directory. (You can take either approach if your notifications are stored in a database, too).
$files = scandir("../".$inboxpath);
$notifications = array();
foreach($files as $file){
if(!is_dir($file) && substr($file, -5) == ".json"){
$notifications[] = array("@id" => $base."/".$inboxpath."/".$file);
}
}
$inbox = array( "@context" => "http://www.w3.org/ns/ldp#"
,"@id" => ""
,"@type" => "ldp:Container"
,"contains" => $notifications
);
$inboxjson = json_encode($inbox, JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES);
header("Content-Type: application/ld+json");
echo $inboxjson;
If you want to restrict access to your notifications, this is a good place to check the request against the authentication method of your choice (eg. a token in the Authentication header, or a signature of some kind).
Now that's all done, you can put your script on a server and check it works with the LDN Receiver test suite. If it does, submit an implementation report!
Part 3: Advertising your Inbox
In order to be useful, you need to make your Inbox discoverable by sender and consumer applications. You can do this by modifying any resource on the Web which you control (like a blog post or your website homepage) to link to the Inbox with the ldp:inbox relation. This can be with an HTTP header:
Link: <https://example.org/inbox.php>; rel="http://www.w3.org/ns/ldp#inbox"
or RDF link, eg. JSON-LD:
{
"@context": "http://www.w3.org/ns/ldp",
"@id": "https://example.org/profile",
"inbox": "https://example.org/inbox.php"
}
eg. RDFa:
<link href="https://example.org/inbox.php" rel="http://www.w3.org/ns/ldp#inbox" />
And that's all there is to it! The complete script is available here, for your copy-pasting pleasure (Apache 2.0 licensed).
Alternatives
If you don't fancy writing your own script to handle LDN receiving, there are few existing implementations you could self-host on your own server. Plus Linked Data Platform servers work out of the box as LDN receivers, so maybe you want to set one of those up.
Week in review: 17 - 23 July
Net magazine (WHSmiths)
5.99gbp (€6.77 / $7.81 / £5.99)
Web Standards Column: Linked Data Notifications
This article was published in issue #296 (Summer 2017) of net magazine!
You may by now have come across the notion of 're-decentralising' the Web, particularly the Social Web. This is about gaining better control over where we store our personal data. It has become common practice to hand over our data to a few major companies in exchange for 'free' services like games, productivity apps, email, and of course social media. Linked Data Notifications (LDN) is a W3C Recommendation, and one of several protocols standardised by the Social Web Working Group as a core mechanism to make decentralisation possible.
Decentralisation
Right now, when you get a notification from your favourite social networking app (or your calendar, or your hotel reservation site) you can view it once within that closed system, and then it tends to disappear. Imagine if you could choose a trusted location to store your notifications data (for example a personal data store or server) and grant access to different applications. Notifications are no longer locked in to the system which generated them in the first place; data from one application can be reused by another.
There are clear benefits of this practice. The end user is free to switch between applications without having to input the necessary data from scratch each time, as well as changing where their data is stored without disrupting the apps they use, because applications can just re-discover the new location. This benefits application developers too, who can now focus on their core product or service. LDN integration means that applications can nonetheless enhance their functionality when users choose to share notification data from complementary services, and benefit from a standard mechanism for doing so rather than depending on the proprietary API of a third-party social network provider.
The Protocol
LDN is a simple HTTP-based protocol which describes three roles in notification-oriented interactions: senders, receivers, and consumers. Any resource on the Web (from a user profile to a single blog post) may advertise a receiving endpoint (their "Inbox"). Doing so is like pointing to a webhook URL, with LDN standardising the discovery mechanism. The receiver accepts requests from senders (for new notifications) and exposes received notifications in a standard format for other applications (consumers) to reuse. The sender can place any data in the contents of a notification - as much or as little as the application determines is useful for its own future reuse, or for sharing with other consumer applications in the same domain. Consumer applications which discover and read in the notification data could use notification contents to trigger another process in a system, or simply display it in a user interface.
So far we have seen decentralised notifications applied in social networking scenarios, as well as for archival activities and scientific experiments through monitoring the state of online resources, datasets and files, or sensor outputs, and sending notifications when changes occur.
Building Blocks
LDN serves as a building block rather than a complete solution for re-decentralisation. The three roles (sender, receiver, and consumer) can be implemented independently from each other (if you want to build a sender, you don't need to build a receiver to do so), or all together in one system. If you don't want to build your own "Inbox" (and let's face it, most people won't) you can rent one from a third-party you trust. Just like outsourcing the hosting of your social media profile today, but without the service-specific lock-in. No matter where your "Inbox" resides, any application can send notifications there. The protocol works well alongside other emerging or completed W3C standards such as ActivityStreams 2.0, ActivityPub, and the Web Annotations Protocol.
You can get started with LDN today; check out a growing list of reference implementations, and run your implementation against the test suite. Although the standardization process is complete, new implementors are nonetheless encouraged to run the tests and submit the automatically generated implementation reports. The W3C Social Web Community Group is the place to go for follow-up questions and comments about integrating this standard into your applications.
Week in review: 29 May - 4 June
Finally, we did something right.
Publishing your article as HTML doesn't damage your chances after all :)
LDN questions from the audience...
About reference implementations... The test suite automatically checks compliance, and most implementations are open source.
From people who are already considering to include LDN in their projects, asking for technical tips.
Authentication/login part... this isn't part of the protocol, orthogonal.
About LDP and Web of Things... can devices send notifications? What if applications can't use JSON-LD? Well, that's part of the Rec that applications must be able to at least do JSON-LD, but to cooperating applications can use content negotiation to agree on a more lightweight RDF format if they want. It's important for interoperability to be able to send JSON-LD in case a receiver can't understand any other RDF syntaxes; but if your sender and receiver both agree on another format (via the Accept-Post header) they can use that.
Do additions to the simple protocol make it complicated? What about spam? LDN recommends application-specific constraints to deal with issues like this. We don't have a blanket suggestion for how to deal with these kinds of problems in every domain though, we leave it to more focused experts.
LDN is based on Linked Data principles, enables decentralisation, and persistence of data.
csarven presents Linked Data Notifications at ESWC2017... Starting with some motivational use cases in the social web space to which this W3C Recommendation has been applied so far.
At 12, csarven will present Linked Data Notifications.. Come to the talk for an overview, then if you want to integrate a part of the protocol into your existing applications, or build a receiver from scratch, we're both here all week and ready to help!
It was only a matter of time. Lightning talk by csarven about Linked Data Notifications.
Week in review: 26 Dec - 1 Jan
Post created with https://rhiaro.co.uk/sloph
Week in review: 19 - 25 December
Post created with https://rhiaro.co.uk/sloph
🔁 https://twitter.com/csarven/status/810838130228072448
Amy shared https://twitter.com/csarven/status/810838130228072448