Let’s take the example of my resume. I generally update my LinkedIn profile, but almost never the “desktop version” (LaTeX or doc) of my CV. So, when the time comes to forward an up-to-date resume in PDF, I used to copy and paste content from my LinkedIn. But wait, I also need to add my publications (even though bibtex makes the integration easy), the list of my research activities and talks, etc.

So, I’ve build sparqlTeX - a LaTeX class / python script to easily embed SPARQL results into TeX files. Using it, one can directly integrate data from SPARQL endpoints, from RDFa-enabled content (such as the previous talk pages), but also from any microformatted page (any Linkedin profile as they’re using hResume) into a LaTeX document. For the last one, I’m using any23 to convert such data into RDF (actually, any23 is used for any file-based query as it extracts RDF from HTML pages even if they’re not W3C-valid)

The scripts are available on github/sparqltex. They require roquet, and the SPARQLWrapper lib if you want to query remote endpoints. That’s a simple on-demand hack, so corner cases and complex structures are probably not managed directly, but feel free to clone the code, update (and push it back), this is public domain.

Here’s the kind of output that it generates, as you can see it’s synced with my LinkedIn profile or talk pages. And you can obviously also use hyperlinks in the templates, bringing the Web back to your resume !

Work section of my resume from LinkedIn to LaTeX through RDF+SPARQL

Talks section of my resume from RDFa-enabled content to LaTeX with SPARQL

• seatwave – that just launched few days and that gives access to a wide range of events, including (obviously) concerts. Search by location, time-frame, venue (including coordinates!), and redirect to seatwave website to get event tickets. Interestingly, they do rev-share if some tickets are bought in one’s app using their API.
• SendGrid – cloud-based e-mail services. Sending mails, but also – the most interesting part – receiving ones and parsing them. Simply configure a MX, a callback URL, and parse any incoming e-mail, including header, content and attachements – all in a REST-ful way

So, with those 2 APIs in mind, I’ve build SeatTrip – it’s like seatwave meets tripit. Send your plane ticket by e-mail, and get a listing of events that will happen in the area a few minutes later.

Sending a AerLingus ticket about a trip to London, I got the following e-mail in my inbox a few minutes later. First, a featured artist. I’m using our own seevl data to identify the featured artist using its meta-data, and display her/his biography.

Featured artist for your next trip!

Then, the listing of all concerts for the city at that time.

All concerts happening during your trip

For each event, it provide additional information from the seatwave API. First, it features a Google Map link to the venue (useful to buy your hotel nearby!).

Use GoogleMap to display the venue map

Also, it links to the seatwave website so that you can directly book your concert – and lists the number of remaining tickets if the show is almost sold-out!

Buy tickets from the seatwave website

Here’s now the fun part, about how this hack works:

• First, once the e-mail is sent to an address mapped to SendGrip API – a PHP script extracts the location and the timeframe of the trip from the e-mail. The extraction if airline-specific, and so far the hack works only on AerLingus ticket (however, an abstraction layer allows to easily create new wrappers – a similar strategy as used in TripIt).
• Then, the seatwave API is used to get the list of all events in the area for that period, including all events details.
• Once we have the events, seevl is used to identify the featured artist from the list of available concerts.
• Finally, the e-mail id rendered in HTML, and send via SendGrid.

It takes around 2 minutes to do the whole processing, check this short video to see it in action. Note that I changed the trip date as that was an old trip ticket for which seatwave didn’t get any data, and that the video has been cut to avoid the delay of receiving the e-mail with the listing.

Also, don’t forget to check this impressive list of 62 hacks - especially Buddhafy (mind-control for Spotify !) and Concerts2021 – the future of live gigs (or not, thanksfully !

In particular, I’d give my thumbs-up for Tourrent - helping bands to set-up their next tours based on Torrent downloads of their tracks, FlatDrop - Micropayments for Soundcloud tracks, and Badgify - audioscrobbler meets Arduino.

Together with Ian from rd.io and Guillaume from Webdoc, we’ve worked on a new music discovery approach, leveraging real-world data. Various 4-square hacks enabling geolocation-based discovery have been build on previous MHD, so we’ve decided to take another route: take a picture of anything, and play the songs that reference this thing. Whether it’s a bottle, some brown sugar, or a house.

So here’s Mixture, a simple hack / proof-of-concept of the approach, combining APIs from IQ Engines (image recognition – give it a try if you’re looking for something similar, even though queries can be a bit slow), musiXmatch (lyrics identification), rd.io (music streaming) and seevl (artist data). It may still be buggy (we’ll work on it) and some APIs have a daily-rate limit that could block the application, but you should be able to get the overall idea!

I wanted to write about our use of Content-Negotiation for a long time, and as we recently switched to JSON-LD as the unique format to represent our data, I decided to talk about both in this blog post.

As you may know (or can guess when checking the team page), we have been involved in efforts around the Semantic Web and Linked Data for many years, and are big fans of the graph model that these technologies offer. It’s flexible, it’s agile, and it’s a straightforward way to integrate and mash-up data from different sources. But when it comes to providing this data back to developers, things are more complex. One could chose to offer RDF/XML or Turtle, but that generally requires a new skillset. Why ? Because most platforms provide JSON, and developers are consequently more used to this than to other formats. Check in particular these recent stats (slide 22-24) from a talk that John Musser (ProgrammableWeb) gave at SemTech this year.

So, we decided to use JSON-LD for our data, after an initial home-grown JSON-modeling, that was not that far from the current JSON-LD spec. One thing I particularly like is that it enables to send “objects” over the wire rather than as a set of triples. For instance, consider this representation of facts about the Beatles:

{
    "@context": {
        "collaborated_with": "http://purl.org/ontology/mo/collaborated_with",
        "id": "http://purl.org/dc/terms/identifier",
        "origin": "http://purl.org/ontology/mo/origin",
        "prefLabel": "http://www.w3.org/2004/02/skos/core#prefLabel",
        "uri": "@subject"
    },
    "collaborated_with": [
        {
            "id": "hSmwe4Dq",
            "prefLabel": "The Quarrymen",
            "uri": "http://data.seevl.net/entity/hSmwe4Dq#id"
        }
    ],
    "origin": [
        {
            "id": "px6UYEPh",
            "prefLabel": "England",
            "uri": "http://data.seevl.net/entity/px6UYEPh#id"
        },
        {
            "id": "xMgUSM9b",
            "prefLabel": "Liverpool",
            "uri": "http://data.seevl.net/entity/xMgUSM9b#id"
        }
    ],
    "prefLabel": "The Beatles",
    "uri": "http://data.seevl.net/entity/pzkVnsbP#id"
}

If you are used to JSON, you probably understand with no additional effort, and can use any JSON toolkit to parse it. If you are aware of the Linked Data principles, you directly see that every entity has its own URI, that can also be accessed to get more infos about it. And if you care about triples, you can use a JSON-LD parser or the public playground, that will understand the @context values to translate this JSON-LD feed into raw triples (using MO and SKOS here). Clearly, the best of both worlds.

Then, Content-negotiation. When using a website and then deciding to develop around it,  I am often frustrated by the need to learn new URLs, new paths, new parameters. Why the hell humans and machines should have different way to access the same data, albeit in different formats ? This is exactly why we rely on Content-negotiation on data.seevl.net. By default, every page is rendered as HTML, but if you ask for JSON, you’ll get a JSON-LD representation of the same entity, separated into different “slices” (infos, link, facts, topics and related artists, as detailed on our dev zone). No need to learn new URIs, no additional paramaters. Just tell us you want JSON, and we’ll serve you what you need !

curl http://data.seevl.net/entity/?prefLabel=beatles
-H "Accept: application/json" -H "X_APP_ID: 1c55b80a"
-H "X_APP_KEY:65e7fbe154e8cee6c1704a9358dd8939"

Content-negotiation + JSON-LD

The best of both worlds.

var hours = 24; // Reset when storage is more than 24hours
var now = new Date().getTime();
var setupTime = localStorage.getItem('setupTime');
if (setupTime == null) {
    localStorage.setItem('setupTime', now)
} else {
    if(now-setupTime > hours*60*60*1000) {
        localStorage.clear()
        localStorage.setItem('setupTime', now);
    }
}

I’ve setup this Tumblr for random notes, pics, etc. and a few longer posts. Yet, I guess that most of the blogging side will be on http://blog.seevl.net – both from the tech and the business side, discussing what we’re building over there in the music and data space. I’ll try to link them – or crosspost some bits and pieces – from here.

You’re passionate about music? Want to join a team working on state-of-the-art Linked Data, Social Semantic Web and NoSQL technologies? Want to work with third-party services to let them know what they can do with our data? Let’s join the team! We are currently looking for interns on Web Engineering and Business Development. The internships last between three and six months and are based in Galway, Ireland.

About Us

Seevl provides a new way to explore the cultural and musical universe of your favorite artists, and lets you discover new ones by understanding how they are connected. We are a spin-out of the Digital Enterprise Research Institute (DERI), at the National University or Ireland, Galway. DERI is the world’s largest Semantic Web research institute, and Seevl brings together several years of R&D on the Semantic Web, Linked Data, Social Web and Web Science areas.

About You

You are passionate about Music, Social Web and Linked Data technologies. You think that the Web could be a better place for music discovery if data was more integrated, structured and interlinked – and also more open. You want to investigate the related engineering or business development challenges.

Required Skills

• Good written and oral communication
• Motivation, autonomy and self-organisation
• Ongoing appetite for knowledge
• Good musical knowledge, whatever the style is

Additional Skills for the Engineering Position

• Python, Django, HTML, Javascript
• RDF(S), Linked Data, APIs, REST architectures

Additional Skills for the BizDev Position

• Knowledge of the Music and / or Web industries
• Interest in Open Source / Open Data and related business models

Benefits

• The opportunity to work on exciting and emerging Web standards and to integrate Music and technology in a brand-new product
• A stimulating, dynamic and multi-cultural workplace combined with a spin-out environment, having strong ties with world-class researchers
• Flexible working hours and free coffee

Want to apply?

Great. Please send us your resume (or LinkedIn profile), a short statement on why you are interested and some links to your blog and Twitter account to jobs[AT]seevl.net. For the engineering position, please send a link to your github account (or equivalent).

The DERI Social Software Unit and the Unit for Information Mining and Retrieval invite applications for an applied research postdoctoral position for 14 months on real-time data-integration and recommendations for the Social Semantic Web, in the context of the ADVANSSE proposal funded by Cisco systems. The position is expected to start on the 1st of February.

Requirements

Candidates should have a PhD degree in a relevant field of study, e.g. Social Web, Semantic Web, recommendation systems, Web engineering, etc.
The position is for a fixed period of 14 months with the possibility of extension, depending on successful acquisition of project funding in which the selected candidate will be expected to actively participate during his time in DERI. The selected candidate should be able to combine formal scientific work, published in top-class conferences and journals, with application-oriented research and development (proof-of-concept).

Essential skills

• A PhD, typically in a computing-related discipline, with a strong applied component
• A record of published research in the aforementioned domains
• Research experience on the Social Web, Semantic Web, recommender systems and Web engineering
• An ability to work in an interdisciplinary team
• An ability to comfortably combine research with applied work
• An ability to develop and manage their own research agenda
• Commitment to deliver on project milestones
• Experience in software development

Desirable skills

• Knowledge of standardisation work
• Industry experience
• Experience in the preparation of research grant proposals
• Experience in student supervision

Informal Inquiries

For informal enquiries about this post please contact Dr. Alexandre Passant alexandre.passant AT deri.org and Dr. Conor Hayes conor.hayes AT deri.org

Position Applications

Interested candidates should send a detailed CV, a one page statement describing their research interests, experience and suitability for this position, and the names and addresses of two referees.
Applications may be sent, in a single PDF file, to alexandre.passant AT deri.org