In this blog post, I will introduce a new web service called People Aggregator. I will point out interesting things they have with their vision of People Aggregator and its relation with Talk Digger; I will explain the advantages and disadvantages of developing Web API or using annotated RDF documents in HTML files; and finally I will introduce the SIOC ontology to Marc Canter.

 

What can you do with PeopleAggregator?

If we refer to this slideshow, you will find that there are really interesting things to do with People Aggregator:

 

• Import your profile from other social networks and keep it in synch across networks
  Connect, create and communicate across networks
• Establish relationships, join/create groups, send messages, import/export content
• Post all kinds of content, from anywhere you like microcontent, blog posts, media, people showcases, recipes, and more
• Interconnection between sites and services, using open standards
• Portability of data
• Tens of millions of decentralized networks outside the control of large companies

 

For them who read my blog for some time will find that this is the vision I had while developing the next generation of Talk Digger. It is not only that, it is the vision I have for the future of the Web. It is not only a question of openness; it is a question of communities’ interaction. And to reach those communities interaction, we need, in fact, data openness.

When I read such features, I also think about the SIOC ontology, you can’t miss the relations.

 

What’s next with People Aggregator?

 

• We need to work with web services developers to flesh out the mesh
• We need to identify standards within domain areas
• We’re going to build all sorts of mashups to show the potential

 

The only thing I can say here is: contact me Mr. Canter, me and the SIOC community are only waiting for people/entrepreneur like you to work with.

 

The current state of People Aggregator: it doesn’t do what it is supposed to do

Okay, I was really excited to read all that stuff and started to dream of People Aggregator interacting with Talk Digger and other web services.

So I created an account and: nothing. I was not able to import and/or export my FOAF or hCard profiles, I was even not able to delete my account.

I checked their developers Wiki without any success considering that the API and its documentation is currently under construction.

Okay well, so all these beautiful words without anything real?
Well… yes and no. Currently no, but it seems that in a near future yes:

Marc Canter wrote that comment on the Read/WriteWeb blog:

 

FOAF and XFN/hCard support are coming – I PROMISE! But we HAD to hit Gnomedex as a deadline – so we shipped with what we got. Remember nobody is funding this – but me.

Meanwhile there’s one subtle thing I’d disagree with Richard’s excellent article. He implies that you NEED to use PeepAgg to achieve all this.

Well today you do – but we’re hoping that the APIs and open data structures (like FOAF and XFN/hCard) will be adopted by others – so others can provide the same functionality. In fact we NEED that to happen or else we’ll be all by ourselves in our sandbox.

So we’re not saying you HAVE to use PeepAgg or that your data eventually resides inside of PeepAgg. We’re just showing the way, we’re giving the APIs that we develop to the community so they are – in fact – NOT proprietary.

And standards like Microsoft’s contact list can be meshed into our web, just as easily as FOAF or XFN. The underlying principle is of inclusion – and particiaption by all.

 

I totally understand the decision he took to hit Gnomedex. He had to create the front-head first to attract people and possible investors at Gnomedex and other conferences. The only thing that is sad is that all his system/concept is about the API and the open data structures. However, I have no doubts that these features are coming soon.

What I really enjoy is that he has the same vision of People Aggregator as the one I have with Talk Digger.

 

Open documents or Web API?

With Talk Digger, I didn’t chose to develop a Web API to let other web services access its data, at least for now. Instead I choose to annotate all my HTML pages with RDF content (SIOC, FOAF, etc). That way, any crawlers/agent software can crawl Talk Digger’s website, read these file, and do what they want to do with the data.

People Aggregator seems preferring to use a Web API to deliver their content.

Which method is best? No one, they both have good and bad.

The advantage of annotating HTML files with RDF content is that as soon as a crawler/agent software can find, read and interpret an annotated documents in a HTML web page, it can read and interpret it everywhere: Talk Digger, Live Journal (with their FOAF), People Aggregator (if they would do that), WordPress blogs using the SIOC ontology plugin, etc, etc. The problem is that it is slow considering that they have to crawl each web page if they want that content.

The advantage of using a Web API is that it is much faster to get the content, probably much reliable and give request flexibility. The problem is that you have to make your software understand the API for each such service (for example, I would have to develop functions to interact with Talk Digger, Live Journal and People Aggregator) if I want to let my software interact with each of these systems.

 

Mr. Canter, think about the SIOC ontology

Mr. Canter, do you know what is the SIOC ontology? No? So read this:

This is exactly what you have to implement in People Aggregator. What is the SIOC ontology? There is the abstract of the talk Uldis will do about the SIOC ontology at the BlogTalk Reloaded conference:

 

Semantically Interlinked Online Communities (SIOC)

http://rdfs.org/sioc/ is a framework for expressing information

contained within weblogs and online community sites in a machine

readable form. It consists of a SIOC ontology that defines the

vocabulary used to express this information and SIOC data exporters

that provide SIOC data from these sites.

Now that SIOC data export plugins are available for popular blogging

and CMS platforms (e.g., Drupal, WordPress, DotClear) we can use this

information to provide users with better and more interesting

services. This talk describes the SIOC browser

http://rdfs.org/sioc/browser – a tool, currently in development, that

allows to browse the information extracted from weblogs. It can be

considered the first generation of consumers of SIOC data.

Two features that distinguish SIOC are: (1) that all the entries of a

weblog are exported; and (2) that all this information is in a machine

readable form. This allows to make queries over the information

exported from a blog or set of blogs – such as retrieving last post

from a user on a given topic, identifying “hot topics”, and so on.

The browser works in two modes – on-the-fly mode and crawler mode. The

former displays the SIOC data received from a weblog (thus providing a

uniform interface to all SIOC-enabled weblogs) while the later stores

SIOC data in the RDF data store allowing to make more complicated

queries via the use of SPARQL query language.

Since the information is published in SIOC – an open and public

standard – the same information source (a weblog or a multi-user blog

site) can be interpreted by many different users in a number of

different ways. This enables to develop a whole kind of browsers

similar to what happened with the emergence of RSS feed aggregators.

The browser presented here is one of the first in this group.

 

The FOAF import/export are developed in Talk Digger and the SIOC ontology is integrated as well in its next generation (the alpha version will be online by the end of the month). I started to check with Uldis and Alex how it could be used, extended, etc. This ontology is really promising and a good starting point for the Semantic Web vision that many people share.

What I try to do is trying to implement all these ideas (semantic web) in a real world, somewhat large scale, application. I know that it has a real potential, but I don’t think people will start adopting these technologies before viewing its potential. So it is what I am trying to do: showing them how it could be used, what are the advantages and its potential.

Mr. Canter, the only thing I can suggest you is to implement the SIOC ontology in People Aggregator and start talking with the SIOC (really active) community to make their vision, that is the same as yours, a reality.

Technorati: Peopleaggregator | talkdigger | sioc | foaf | microformats | semantic | web | communities | open |

Some days ago I was checking how I could use the SIOC (Semantically Interlinked Online Communities) ontology to broadcast/share Talk Digger’s content in a meaningful way. (read more: Using SIOC ontology to connect Talk Digger with other online communities)

 

The implementation using RDF

Now it’s time to implement it by formatting that content using RDF/XML following the ontology’s guideline.

To create a good ontology you have to process by iteration: refining the ontology with testing and peer reviews.

Implementing an existing ontology in a system (such as Talk Digger) also has that process: generating a RDF file accordingly to the ontology and then trying to figure out how to link everything together (defining URI classes, defining resources, linking to resources, etc.) to optimize the graph (optimizing the relations betweens the resources to have as much meaning (easy to query) as possible).

 

Visualizing the RDF graph using IsaViz

The tool I used to implement the SIOC and the FOAF ontologies in Talk Digger is a RDF editor/visualization tool called IsaViz.

My procedure was simple:

1. Generating the RDF/XML files (accordingly to SIOC and FOAF) with Talk Digger’s content database.
2. Importing the RDF/XML file in IsaViz.
3. Visualizing and analyzing the resulting graph.
4. I checked all the relations between the resources and tried to figure out if it was possible to cut/add some of them to simplify/optimize the resulting graph.
5. I checked all the anonymous nodes (bNodes) of the graph and checked if it was possible to relate them to an existing resource.
6. I performed these 5 steps until I was satisfied by the resulting graph.

 

Playing with URIs and xml:base

What is great is that I can distribute Talk Digger’s content anywhere on the Web (with different URLs) and a crawler can download all these snipped of content (FOAF profiles, conversations content, etc.), aggregate them and merge them in a unique RDF graph. That way they can have their hands on all the relations that exist in the Talk Digger system and then querying it(the RDF graph) in useful and meaningful ways.

All that magic is possible by the fact that we can define a different URI for a given RDF/XML document using the xml:base attribute. That way I can:

 

• Host a RDF/XML document at the URL http://talkdigger.com.com/a.php
• Define the xml:base with the URI “http://talkdigger.com.com/db/”

• Host a RDF/XML document at the URL http://talkdigger.com.com/b.php
• Also Defining the xml:base with the URI “http://talkdigger.com.com/db/”

 

Then if a crawler downloads both RDF documents “a.php” and “b.php”, it can merge them to recreate the single RDF document defined at “http://talkdigger.com.com/db/”. By example, this merged RDF document would be the graph of all relations defined between Talk Digger’s content.

 

Talk Digger’s URI classes

I refer to a “URI class” when I talk about a “part” of a URI that is general to many URI “instances”. I refer to an “URI instance” when I talk about a URI that refer to a resource.

By example, the “URI class” of Talk Digger subscribed users is:

http://www.talkdigger.com/…/user.php?nick=

But an “instance” of that “URI class” would be the URI that describe a particular Talk Digger user:

http://www.talkdigger.com/…/user.php?nick=fgiasson

In that example, this “instance” refers to a resource that is the Talk Digger subscribed user called “fgiasson”.

There are the “URI classes” defined in Talk Digger:

• URI class referring to a conversation container (work as a container for the conversation components)

http://www.talkdigger.com/…/conversation.php?url=[$url]

• URI class referring to a conversation

http://www.talkdigger.com/…/conversation.php?url=[$url]#conversation

• URI class referring to a usergroup (a group of users tracking that conversation)

http://www.talkdigger.com/…/conversation.php?url=[$url]#usergroup

• URI class referring to a subscribed user

http://www.talkdigger.com/…/foaf.php?nick=[$nick]

 

SIOC and FOAF instances generated with Talk Digger content

In the next sections I will show you how Talk Digger will use the SIOC and FOAF ontologies to broadcast/share its content.

I’ll use 3 RDF documents for my presentation:

1. sioc-fgiasson.rdf. This file describe the conversation evolving around my personal website [fgiasson.com] (in fact it is only a snippet for the example’s sake).
2. foaf-fgiasson.rdf. This file is the FOAF profile of my Talk Digger user [fgiasson].
3. sioc-blogspot.rdf. This file describe the conversation evolving around a specific blog post on a Blogspot blog called “Guilty of being…”. This blog post refers to an article I wrote on my blog.

All the RDF graphs have been exported in SVG files from IsaViz. Many mainstream applications like Visio or CorelDraw can read these files. If you don’t have access to one of these software you can refer to that list of tools to read SVG files (I am unfortunately not able to find any tool to convert a SVG file into a huge JPEG or GIF file).

Note: the path of the interesting results I found in these graphs are highlighted in red.

 

The SIOC document describing the conversation evolving around fgiasson.com

You can download the RDF document here: sioc-fgiasson.rdf.

The resulting RDF graph of this document is available here: fgiasson-conversation.svg

What is interesting in that graph is the interaction between

-a sioc:User
-[http://www.talkdigger.com/…/user.php?nick=fgiasson]

-a sioc:Usergroup
-[http://www.talkdigger.com/…/conversation.php?url=fgiasson.com#usergroup]

-some sioc: Post
-[http://www.talkdigger.com/…/conversation.php?url=fgiasson.com#comment-1]

-a sioc:Site
-[http://talkdigger.com]

-a sioc:Forum
-[http://www.talkdigger.com/…/conversation.php?url=fgiasson.com#conversation]

 

Merging a FOAF document with this SIOC document

Now I merged the FOAF document that describe more in deep my sioc:User fgiasson.

You can download these RDF documents here: sioc-fgiasson.rdf, foaf-fgiasson.rdf

The resulting RDF graph of these documents is available here: fgiasson-conversation-foaf.svg

The link between the FOAF to the SIOC document is made using the foaf:holdsAccount property. The result is:

[http://www.talkdigger.com/…/foaf/foaf.php?nick=fgiasson]
— foaf:holdsAccount —>
[http://www.talkdigger.com/…/user.php?nick=fgiasson]

The link between the SIOC to the FOAF document is made using the rdfs:seeAlso property. The result is:

[http://www.talkdigger.com/…/user.php?nick=fgiasson]
— rdfs:seeAlso —>
[http://www.talkdigger.com/…/foaf/foaf.php?nick=fgiasson]

If you take a closer look at the resulting RDF graph, you will see that I highlighted a “loop” in red. This is one of the really interesting results when you merge different ontologies.

What is happening here? By merging the FOAF document of the “fgiasson” user with the SIOC document of the “fgiasson.com” conversation, I uncovered some interesting relations.

In fact, the sioc:User “fgiasson” is a friend of “dgiasson” another sioc:User. However, it was impossible to know that fact before merging the two documents because that information is held in the FOAF document and not the SIOC one! At the same time, we know that “fgiasson” and “dgiasson” also belong to the same sioc:Usergroup
[www.talkdigger.com/…/conversation.php?url=fgiasson.com#usergroup].

That way we are able to extend the power of our queries because we are able to know who are the people that belongs to a sioc:Usergroup and that are also friends. We could possibly even extend that feature by using the “relationship” ontology and then developing some type of trust networks by analyzing the relationships between people belonging to a same group.

 

Merging a new SIOC document to that RDF graph

Finally I merged another SIOC document that describes a conversation evolving around a blog post that link-back to the conversation about “fgiasson.com”.

You can download these RDF documents here: sioc-fgiasson.rdf, foaf-fgiasson.rdf, sioc-blogspot.rdf

The resulting RDF graph of these documents is available here: fgiasson-conversation-foaf-other-conversation.svg

In this graph I highlighted in red the fact that a sioc:User “fgiasson” is a member of two different sioc:Usergroup and that a sioc:Forum is the parent of another sioc:Forum.

 

Conclusion

In this blog post I described how I would use the SIOC and the FOAF ontologies to share the content available on Talk Digger.

There are probably some glitches, errors, or best-practices (I don’t follow) in the way I handle some classes and/or properties of these ontologies (specially about how to relate a sioc:User and a foaf: Person). Considering this it would be really appreciated to report any glitch/errors/best-practices you find to help me improving this implementation in Talk Digger.

Technorati: sioc | foaf | semantic | web | rdf | talkdigger | xml | svg | ontology | online | communities | conversation |

Talk Digger: “Semantic Web Ready”

As you probably know, I am currently working on a new version of Talk Digger since a couple of months. One of the features I wanted for this new version was to make Talk Digger “Semantic Web Ready”. I wanted to be able to broadcast its content data in such a way that people could create new services above it.

 

SIOC ontology to describe Talk Digger’s online community

Since, I mostly finished developing the infrastructure, the features and the user interface of the next version of Talk Digger. Then I started to think about this problem. At first I was thinking to develop an ontology to describe what is a “conversation evolving on the Web”. Then started to refresh my memory on the best practices to develop an ontology. One of the first steps was to search for ontologies I could re-use in the one I was expecting to develop. I have done my research using Swoogle. I finally found the SIOC ontology (Semantically-Interlinked Online Communities). I started to read their publications, the specification, and the forums and then I found exactly what I needed.

At a first glance, when you read the class and property names, you can’t do any correlation between that ontology and Talk Digger. However, when you start reading their descriptions and start to map the SIOC terms with the Talk Digger functionalities, you start to see emerging how Talk Digger is becoming an online community.

After I realized that the SIOC ontology is exactly the ontology I wanted to develop for Talk Digger (even if the names are not really relevant with Talk Digger’s). Also, using existing ontologies is always better than creating new ones. For these reasons I choose to use SIOC to share Talk Digger’s content to the world and making it “Semantic Web Ready”

First of all, I would suggest you to check back these screenshots of the new version of Talk Digger before continuing to read this post:

Some screenshots of the next generation of Talk Digger

 

Mapping SIOC classes and properties to Talk Digger functionalities

The first step if to map the SIOC ontology terms to the Talk Digger’s web site functionalities. Take a look at the schemas bellow to check that mapping. At the left you have the SIOC ontology classes and properties (I only put the properties that create relations between classes. Properties like sioc:topic, sioc:description, etc. are not on that schemas for clarity’s sake). At the left you have the Talk Digger system. In the middle you have the relations between the SIOC ontology and Talk Digger.

 

[Click on the schemas for the Full View]

 

Description of the schemas

• The sioc:Site instance is Talk Digger’s web site (talkdigger.com)
• A sioc:Forum is a Talk Digger conversation page. I consider that a conversation page is a forum. The topic is in relation with the web document that started the conversation. So each time that a new URL is tracked by Talk Digger, then a new “forum” is also created. Forums are interlinked together, so if a url A and B are tracked by the system and that the web document at the url B link to the url A we will have: sioc:Forum(A ) – sioc: parent_of –> sioc:Forum(B ) AND sioc:Forum(B ) — sioc:has_parent –> sioc:Forum(A )
• A sioc: Post is a comment wrote by a Talk Digger user on a conversation page. So each time a user write a comment, a sioc: Post is created in the sioc:Forum.
• A sioc:User is a Talk Digger user. A Talk Digger user is defined by his internal and unique username. The personal description of the sioc:User is related (via the rdfs:seeAlso property) to it’s FOAF profile (archived in the Talk Digger System).
• Each time a conversation page is created in the system, a related sioc:Usergroup is also created. Each time a user start to track that conversation using Talk Digger, it also subscribe to the sioc:Usergroup. So: sioc:User(A) — sioc:member_of –> sioc:Usergroup(conversation)

 

Special case with sioc:Forum

As I said above, two sioc:Forum can be linked together if a url A and B are tracked by Talk Digger and that the web document at the url B link to the url A.

But what happen if the url A link to the url B too?

 

 

There is a circular loop in the model: both sioc:Forum are child and parent.

In the context of Talk Digger, it tells me that A is part of the conversation started by B and B is also part of the conversation started by A. It makes sense in that point of view.

However I am not sure that it semantically makes sense in the context of the SIOC ontology.

 

sioc:reply_of and sioc:has_reply to recreate the course of events

The sioc:reply_to and sioc:has_reply of the sioc: Post class are really great in the context of Talk Digger (and blog comments) because systems will be able re-create the course of events, without needing dates, only by following the graph created by these relations.

 

Conclusion

In the next days I will implement the SIOC ontology in Talk Digger and then I will post a snippet of the generated code for peer review.

I am pretty sure that using the SIOC ontology in Talk Digger will give the possibility to other people to use its content in a pretty and novel way.

I could even make Talk Digger a SIOC data warehouse that could crawl SIOC content sites and add them into Talk Digger conversations.

 

Technorati: sioc | online | communities | semantic | web | talkdigger | rdf | xml | owl |