A few days ago, at the recommendation of @cgutteridge, I changed the default FOAF class from foaf:Person to foaf:Agent, when representing Twitter users.

As Christoper rightly pointed out, foaf:Person is used specifically to represent real-live people, whereas many of the accounts on twitter are either organisations or bots of various kinds. As such, foaf:Agent is the more appropriate class.

It would be great, of course, if Twitter allowed you to specify whether the account was for a real person or some other entity, but doesn’t (yet) allow you to do so.

I wrote previously about a report in TechCrunch about Twitter growing uncomfortable with people using the term ‘tweet’ in applications.

TechCrunch has just provided a further update to this story.

I’ve had a number of mails from people in the past few months, saying that they had discovered their name, whether real name or twitter alias, on a semantictweet.com page as a result of a Google search. Sometimes their name may have appeared on the same page as other less savoury twitter accounts (e.g. twitter porn accounts, or twitter spam accounts).

More often than not, these people do not what their twitter name being indexed with other unsavoury names, and want the offending semantictweet.com page to be removed. I’ve occasionally even been threatened (spuriously, I’ve no doubt) with legal action if I fail to comply.

As I have explained in the past, and for the benefit of anybody who finds themselves in this position in the future, I’m afraid that this is not possible on a selective basis.

Let me recap how semantictweet.com works. When you retrieve (or dereference) a SemanticTweet URL such as semantictweet.com/<<somename>>/friends, this provides you with the list of twitter friends of @somename.  Try it out with http://semantictweet.com/semantictweet/friends.  Likewise, http://semantictweet.com/semantictweet/followers will give you the list of twitter followers.

If all has gone well, you’ll end up with a long XML (or more correctly, RDF/XML) document that looks something like this:

<rdf:RDF>
  <foaf:PersonalProfileDocument rdf:about="">
    <foaf:maker rdf:resource="http://semantictweet.com/semantictweet"/>
    <foaf:primaryTopic rdf:resource="http://semantictweet.com/semantictweet#me"/>
    <admin:generatorAgent rdf:resource="http://semantictweet.com/"/>
    <admin:errorReportsTo rdf:resource="mailto:[email protected]"/>
  </foaf:PersonalProfileDocument>
  <foaf:Person rdf:about="http://semantictweet.com/dominikb1888#me">
    <foaf:name>Dominik Böhler</foaf:name>
    <foaf:nick>dominikb1888</foaf:nick>
    <rdfs:seeAlso rdf:resource="http://semantictweet.com/dominikb1888"/>
    <foaf:homepage rdf:resource="http://www.wi1.uni-erlangen.de"/>
    <foaf:img rdf:resource="http://a3.twimg.com/profile_images/414507117/twitterProfilePhoto_normal.jpg"/>
  </foaf:Person>
…
</rdf:RDF>

It’s these pages that are indexed by Google, and usually the cause of the kind of request that I described above.

SemanticTweet works by querying the public Twitter API of the user in question.  SemanticTweet doesn’t store or cache anything – it just runs the query, and then builds the RDF document shown above from the data returned by Twitter.

Here’s the key point:

SemanticTweet only uses publicly available data provided by Twitter.

What this means is, that there is no way to individually block or remove particular page (without changing the code to explicitly do so). The way to remove a SemanticTweet page is to ensure that you’re not following or friended to the undesired Twitter user. You might even find that it’s necessary to block the offending user. Once you’ve done all that, reload the SemanticTweet URL, and check that everything is as it should be.

Bear in mind, that even taking this step is not necessarily going to be immediate, as Google (or any other search engine) will cache the original, offending page, so you’ll have to wait until Google reindexes the page before the reference is completely removed. Obviously, it is totally out of my hands as to when this happens.

After a couple of great recent mentions in ProgrammableWeb and KillerStartups, SemanticTweet has been named as the site of the day on the Japanese site 100shiki.com.

My complete lack of Japanese means I can’t interpret what the article says, but I’m assuming that it’s reasonably positive.

programmableweb.com has just listed semantictweet in their catalog of mashups.  They have also tweeted about it.

Cool!

I’ve submitted the story to digg, so if you like it, please digg it!

I have just deployed a new version of SemanticTweet. In this iteration, SemanticTweet supports geolocation. Specifically, it attempts to convert your Twitter location into a semantic web equivalent.

Because Twitter allows your location attribute to be free-form text, SemanticTweet must parse the attribute to turn it into something intelligible. At present, SemanticTweet supports four use cases for the location attribute. The following examples all refer to Dublin, Ireland, and can be correctly parsed by SemanticTweet:

1. geonames:2964574
2. Some arbitrary text: 53.3330556,-6.2488889 (lat/long format, as produced by some iPhone twitter clients)
3. Dublin (or any place name, not just a capital city)
4. Dublin, IE (but not Dublin, Ireland)

If SemanticTweet can correctly parse your location, it will attempt to find it on GeoNames. For those of you who are unfamiliar with GeoNames, it describes itself as the:

geographical database [that] covers all countries and contains over eight million placenames that are available for download free of charge.

I’ll go into the GeoNames integration in a subsequent blog post, but for the moment, take it as read that the GeoNames service is queried, and a geolocation obtained. Based on this, SemanticTweet inserts the two <foaf:based_near> triples into your <foaf:Person> profile:

<foaf:based_near>
  <wgs84_pos:Point>
    <foaf:name>Guillestre</foaf:name>
    <wgs84_pos:lat>44.6594959346223</wgs84_pos:lat>
    <wgs84_pos:long>6.64947509765625</wgs84_pos:long>
  </wgs84_pos:Point>
</foaf:based_near>
<foaf:based_near rdf:resource="http://sws.geonames.org/6446645/"/>

(This example was taken from @hubject’s profile, who provided his Twitter location as geonames:6446645.)

The first of these <foaf:based_near> triples is pretty obvious: place name, latitude and longitude. The second of them is somewhat more interesting, in that it is the GeoNames URI for that placename, and that that URI redirects to http://sws.geonames.org/6446645/about.rdf, which is an RDF document describing the place.

Hence, your twitter location is now participating in the great Linked Data world.

At present, this geotagging is only being done for the calling screen name, not their friends or followers. This is principally because of the number of external web service calls necessary, and the associated latency if one were to make hundreds or even thousands of such calls for a large set of friends and followers.

There are, of course, many ways in which this could be improved, not least of which would be to parse the place names more intelligently, but for the moment, this does a pretty good job, and will hopefully make the SemanticTweet service somewhat more useful and interesting.

TechCrunch have posted a report about Twitter growing "uncomfortable" with the use of the word ‘tweet‘ in applications. The post and the subsequent comments are pretty interesting to read in the context of Twitter’s actions in relation to IP & trademarks.

It’ll be an interesting one to follow. On the one hand, you can understand that Twitter want to protect their intellectual assets, including their trade and service marks. On the other hand, this has the potential to alienate a bunch of developers of web services and desktop/mobile clients that have used variations of ‘tweet‘ (including, of course, SemanticTweet) to build their own businesses and consequently improve Twitter’s.

@danja pointed out that there were RDF validation errors in SemanticTweet. Turns out that I hadn’t checked it closely enough before releasing. They key problem was that I was generating a single <foaf:knows> node, with multiple children, rather than one each.

A secondary problem is that some Twitter users don’t provide valid URIs in their profile description, so you have to validate them before creating a <foaf:homepage> node.

Anyway, all that is done, and a new revision of the service is now available.

I’ve just released the first pre-alpha (if there is such a thing) version of the semantictweet service.

Basically, it generates a FOAF RDF document for you from your list of Twitter friends and followers. It does this using the Twitter REST API. This service uses public Twitter data only, and so doesn’t need your Twitter username or password.

One of the benefits of this approach is that it ensures that you don’t have to build and maintain your FOAF file by hand, which is a real pain - this service will dynamically generate it each time its queried.

There’s plenty more to do, and plenty of ways in which Twitter data can be presented in a semantic web way, to allow more and interesting documents to be produced, so watch this space.