The Sun BabelFish Blog

mSpace: web 2.0 meets web 3.0 meets iTunes

Have you ever found the category browsing of iTunes to be a little limited? If so you have to try out mSpace, a Web 2.0 music browser, but also a whole new way of thinking about exploring relational data. Before reading any further just try it out!

So what does that mspace application do? If you have used iTunes and you view it in Browser mode by hitting ⌘B for example, you will have noticed that you are only confronted with three selection panes titled "Genre", "Artist" and "Album". You can't add any more, nor can you re-arrange them. Well the default is good as a default, but if you like to listen to classical music, then you may find that constraining your search by "Artist" is really not quite as interesting as constraining it by "Composer". So really you would like to have three columns "Genre","Composer","Album". This is what mSpace allows you to do. Not only that, but you can add any number of other columns and rearrange these columns any way you want by dragging and dropping them. You can then use this to search the information space the way that makes most sense to you.

As interesting as the UI is the theory behind it. Based on some 4 year old Semantic Web research (see their papers) this recent implementation makes all the points in an instant. For detailed description of the thinking behind this it is worth reading "Applying mSpace Interfaces to the Semantic Web", which gives a Description Logic (which is in short an Object Oriented declarative logical formalism) basis for their work.

A Java version, called jSpace is being implemented by Clark and Parsia. Looks like one just would need to resuscitate the work on jTunes and presto, one could have something a lot more interesting than iTunes, that worked on all platforms. The theory behind this is certainly going to be really useful to help me implement Beatnik.

Digg it.

Posted at 05:40PM Feb 13, 2007 [permalink/trackback] by Henry Story in SemWeb  |  Comments[2]

Beatnik: change your mind

Some people lie, sometimes people die, people make mistakes: one thing's for certain you gotta be prepared to change your mind.

Whatever the cause, when we drag information into the Beatnik Address Book (BAB) we may later want to remove it. In a normal Address Book this is straightforward. Every vcard you pick up on the Internet is a file. If you wish to remove it, you remove the file. Job done. Beatnik though does not just store information: Beatnik also reasons.

When you decide that information you thought was correct is wrong, you can't just forget it. You have to disassociate yourself from all the conclusions you drew from it initially. Sometimes this can require a lot of change. You thought she loved you, so you built a future for you two: a house and kids you hoped, and a party next week for sure. Now she's left with another man. You'd better forget that house. The party is booked, but you'd better rename in. She no longer lives with you, but there with him. In the morning there is no one scurrying around the house. This is what the process of mourning is all about. You've got the blues.

Making up one's mind

Beatnik won't initially reason very far. We want to start simple. We'll just give it some simple rules to follow. The most useful one perhaps is to simply work with inverse functional properties.

This is really simple. In the friend of a friend ontology the foaf:mbox relation is declared as being an InverseFunctionalProperty. That means that if I get the graph at http://eg.com/joe I can add it to my database like this.

If I then get the graph at http://eg.com/hjs

I can then merge both graphs and get the following

Notice that I can merge the blank nodes in both graphs because they each have the same relation foaf:mbox to the resource mailto:henry.story@sun.com. Since there can only be one thing that is related to that mbox in that way, we know they are the same nodes. As a result we can learn that :joe knows a person whose home page is http://bblfish.net, and that same person foaf:knows :jane, neither of those relations were known (directly) beforehand.

Nice. And this is really easy to do. A couple of pages of lines of java code can work through this logic and add the required relationships and merge the required blank nodes.

Changing one's mind

The problem comes if I ever come to doubt what Joe's foaf file says. I would not just be able to remove all the relations that spring from or reach the :joe node, since the relation that Henry knows jane is not directly attached to :joe, and yet that relation came from joe's foaf file.

Not trusting :joe's foaf file may be expressed by adding a new relation <http://eg.com/joe> a :Falsehood . to the database. Since doing this forces changing the other statements in the database we have what is known as non monotonic reasoning.

To allow the removal of statements and the consequences those statements led to, an rdf database has to do one of two things:

• If it adds the consequences of every statement to the default graph (the graph of things believed by the database) then it has to keep track of how these facts were derived. Removing any statement will then require searching the database for statements that relied on it and nothing else in order to remove them too, given that the statement that one is attempting to remove is not itself the consequence of some other things one also believes (tricky). This is the method that Sesame 1.0 employs and that is described in “Inferencing and Truth Maintenance in RDF Schema - a naive practical approach” [1]. The algorithm Jeen and Arjohn develop shows how this works with RDF Schema, but it is not very flexible. It requires the database to use hidden data structures that are not available to the programmer, and so for example in this case, where we want to do Inverse Functional property deductions, we are not going to be easily able to adapt their procedure to our needs.
• Not to add the consequence of statements to the database, but to do Prolog like backtracking when answering a query over only the union of those graphs that are trusted. So for example one could ask the engine to find all People. Depending on a number of things, the engine might first look if there are any things related to the class foaf:Person. It would then look at all things that were related to subclasses of foaf:Person if any. Then it may look for things that have relations that have domains that are foaf:Person such as foaf:knows for example. Finally with all the people gathered it would look to see if none of them were the same.
  All this could be done by trying to apply a number of rules to the data in the database in attempting to answer the query, in a Prolog manner. Given that Beatnik has very simple views on the data it is probably simple enough to do this kind of work efficiently.

So what is needed to do this well is the following:

• notion of separate graphs/context
• the ability to easily union over graphs of statements and query the union of those easily
• defeasible inferencing or backtracking reasoning
• flexible inferencing would be best. I like N3 rules where one can make statemnts about rules belonging to certain types of graphs. For example it would be great to be able to write rules such as: { ?g a :Trusted. ?g => { ?a ?r ?b } } => { ?a ?r ?b } a rule to believe all statements that belong to trusted graphs.

From my incomplete studies (please let me know if I am wrong) none of the Java frameworks for doing this are ideal yet, but it looks like Jena is at present the closest. It has good reasoning support, but I am not sure it is very good yet at making it easy to reason over contexts. Sesame is building up support for contexts, but has no reasoning abilities right now in version 2.0. Mulgara has very foresightedly always had context support, but I am not sure if it has Prolog like backtracking reasoning support.

[1] “Inferencing and Truth Maintenance in RDF Schema - a naive practical approach” by Jeen Broekstra and Arjohn Kampman

Posted at 03:19PM Feb 09, 2007 [permalink/trackback] by Henry Story in SemWeb  |  Comments[0]

foaf enabling an enterprise

Developing the Beatnik Address Book (BAB) I have found requires the software to implement the following capabilities:

1. being able to read rdf files and understand foaf and vcard information at the very least. (on vcard see also the Notes on the vcard format).
2. being able to store the information locally, keeping track of the source of the information so as to be able to merge and unmerge information on user demand
3. being able to write semantic files out at some unchanging location
4. an easy to use GUI (see the article on F3).

I would like to look at 3. the aspects of writing out a foaf file today. At its simplest this is really easy. But in an enterprise environment, if one wants to give every employee a foaf file so as to allow Universal Drag and Drop of people between applications inside the firewall, some questions need to be answered.

General Solution

The main solution and the obvious one is just to write a foaf file out to a server using ftp, scp, WebDav or the nascent Atom Protocol. Ftp and scp are a little tricky for the end user as he would have to understand the relation between the directory structure of the ftp server and its mapping to the web server urls, as well as what is required to specify the mime types of the foaf file, which is very much dependent on the setup of the web server. (see what I had to do to enable my personal foaf file) This may end up being a lot of work with a steep learning curve for someone who wishes to just publish their contact information. WebDav on the other hand, being a RESTful protocol, makes it much easier to specify the location of the file. Wherever the file is PUT that's it's name. Similarly with the Atom Protocol, though I am not sure for either of them how good they are when confronted with arbitrary mime types. My guess is that WebDav should do much better here.
In any case, using either of the above methods one can always later overwrite a previous version if one's address book changes. This is indeed the solution that will satisfy most use cases.

Professional Solution

In a professional setting though, things get to be a little more complicated. Consider for example any large fortune 500 company. These companies already have a huge amount of information on their employees in their ldap directory. This is reliable and authoritative information, and should be used to generate foaf files for each employee. These companies usually have some web interface to the ldap server which aggregates information about the person in human readable form. Such a web interface - call it a Namefinder – could easily point to the machine generated foaf file.

Now the question is: should this foaf file be read only or read/write? If it is read/write then an agent such as the Beatnik Address Book, could overwrite the file with different information from that stored in ldap, which could cause confusion, and be frowned upon. Well of course the WebDav server could be clever and parse the graph in such a way as to enforce the existence of a certain subgraph. So given the following graph generated from the ldap database

<#hjs> a foaf:Person;
             foaf:mbox <mailto:henry.story@sun.com>;
             foaf:name “Henry Story”;
             org:manager <12345#hjs> .

An Address Book that would want to PUT the a graph containing the following subgraph

<#hjs> a foaf:Person;
             foaf:mbox <mailto:henry.story@sun.com>;
             foaf:name “Henry Story”;
             org:manager <#hjs> .

might

• get rejected, because the server decides it owns some of the relations, especially the org:manager one in this case. (What HTTP return code should be returned on failure?)
• or it may decide to rewrite the graph and remove the elements it does not approve of and replace them. That is, replace the triple <#hjs> org:manager <#hjs> with <#hjs> org:manager <12345#bt> for example. (Again what should the HTTP return code be?)

Both of those solutions are valid, but they end up creating a file of mixed ownership. Perhaps it would be better to have the file be read only, officially owned by the company, and have it contain a relation pointing to some other file owned by the user himself. Perhaps something like the following would appear in file at http://foaf.sun.com/official/294551 :

<>   a foaf:PersonalProfileDocument;
       foaf:maker  <http://www.nasdaq.com/SUNW>;
       lnk:moreInfo </personal/294551> .

</personal/294551> a rights:EditableFile;
                    rights:ownedBy <#hjs> .

That is, in plain English the resource would say that it is a PersonalProfileDocument and that Sun Microsystems is the maker of the file and that more information is available at the resource </personal/294551>. It would also give ownership permissions on that resource. A PROPFIND on each of those files could easily confirm the access rights of each of them.

Now from there it should be possible for the user agent ( BAB in this case) to deduce that it has space to write information at </personal/294551>. There it can then write out all the personal information it likes: adding relations to DOAP files, to a personal home page, to interests and to other people known, etc... It could even add a pointer to a public foaf file with a statement such as

<http://foaf.sun.com/official/294551#hjs> owl:sameAs <http://bblfish.net/people/henry/card#me> .

Multiple Agent Problems

Having solved the problem of a writable user agent file, there remains one more distant problem of the same person ending up in a more Semantically enabled future with multiple user agents all capable of writing foaf files but each perhaps with slightly different interests. How would these user agents write files making sure that they don't contradict each other, overwrite important information that the other requires, etc...? The Netbeans user agent may want to write out some relations in the foaf file using the doap ontology to point to the projects the employee is working on... Well perhaps it is as easy as just adding those triples to the file or if then the same problem of ownership arises as above, it may be worth placing each triple into a different user agent space... Well. This seems a bit far out for the moment, I'll look at that problem when I build the next Semantic application. If people have already come across this problem please let me know.

Questions

The above are just some initial thoughts on how to do this. Are there perhaps already relations out there to help cut up the responsibility of writing out these files between different agents be they political or software ones? Are there other solutions I am missing?

Posted at 03:24PM Feb 07, 2007 [permalink/trackback] by Henry Story in SemWeb  |  Comments[2]

Search, Tagging and Wikis

Problem Statement

Large companies such as Sun Microsystems have a number of knowledge management needs. Plain text search engines can help find documents by searching through keywords in document content. The problem is that

1. This can return a huge number of documents
2. The keywords the user is thinking of may not be the right ones
3. The things searched for may not be text documents – they could be pictures, people or things

Search and its limitations

The first problem can be solved using PageRank algorithms such as those used by Google on the Internet, which looks at the topology of the graph made from the links between pages to categorize pages into those that are considered important by the web community as a whole. The second problem can be solved by automatic category extraction tools such as those developed by Exalead which analyze the frequency of occurrence of words in documents to create a graph of the similarity space of concepts. This can be presented to the user who can then find similar concepts to those he is looking for, and so narrow down his search. (I developed a Topic Graph Java Applet at AltaVista to do exactly this.)

On the intranet the PageRank algorithms are not going to be as successful as the user community is much smaller, and the need for people to link to each other's documents less big: those who work on the same topic will tend to know each other well. The value of the link will therefore be less evident.
Concept extraction tools should be much more successful on the intranet, as there will be a lot of high quality content available. But even though they will help narrow down a query to more relevant search terms, they will not help find those documents that are the most authoritative. And so the results returned could just as well be out of date documents, only vaguely related documents, or other irrelelvant ones. The ones everyone in the know is reading will not pop up to the top automatically.

Finally concept extraction tools or keyword searches are not helpful for finding information about documents or things that are not textual in nature.

To find what a company deems the most important one needs the behavioral input of its members. And so the question is really: how does one generate this information.

From Bookmarking to Tagging to Wikis

One thing one can assume is that useful documents or things will be those people keep wanting to return to. Bookmarking is the way to find one's way back to documents in a stable information space - a space where things have reliable links (aka. permalinks) - especially so when search itself is not reliable. Bookmarking is the only solution available to a successful information gatherer apart from search.
As bookmarks lists grow they become unwieldy and so they need to be categorized or tagged, so that the user can find his way around his own private information space. Developing one's own private categorization/tagging scheme is itself complex, time consuming and unreliable. Working with a larger community helps this process dramatically, and so is the first incentive towards helping a lone information gatherer participate in a larger communal structure. Bookmarking tools such as del.icio.us or slynkr just help the information gatherer do what he needs to do anyway.

Once bookmarking services are available and people are busy tagging the resources bookmarked it is possible to find resources that other people have found to be similar (with respect to a tag) to the one one is looking at. This is the beginning of the development of a conceptual scheme. This only requires a space to make these concepts more explicit and to reinforce their use. As tagging commes to be a communal activity the space for defining the concepts develops communally too. It may start as just a helpful suggestion for other tags to use, but it can easily develop into something more informational.
An enhanced wiki would be such an informational space. It would help define the publicly agreed meaning of each tag as its users work on filling out the wiki pages associated with it. This meaning would itself be agreed to communally, that is in a distributed fashion. Writing down the meaning more carefully would help disambiguate the tags and also serve as a repository of knowledge about the concept in question. An empty tag-wiki page would just link to all the documents that had been tagged that way. A more worked upon tag-wiki page would contain information about the meaning of the concept in question, the history of it, the people leading the changes, the place to find technical documentations, other related concepts, and much more. A fully semantic tag/wiki page would express some important elements of that content in terms of machine readable semantic relations.

An Ontology For Tagging

During a week in Zürich we came up with the following elements needed to describe a Tag.

1. the tag
2. the event of tagging
3. the thing tagged
4. the person or agent doing the tagging

This gives the really simple UML diagram:

It is important to distinguish the tag from the tagging event itself, as otherwise one cannot count the number of times a tag was applied to a resource, which is one element in calculating the value of a resource. The other element in keeping track of the value of the resource is to find out who did the tagging, as the value one gives to the Tagger flows to the tagging event.

Finally it is important in a Tag to keep track of the schema of the tag. Tags evolve within a social context - be it one provided by flickr, del.icio.us, stumbleupon or slynkr - and this social evolution gives them particular meaning. The label “bank” will end up being associated with a very different tag if part of a tag cloud at a large banking institution or if part of a tag cloud in an environmental agency. Using URL scheme (as opposed to URN schemes as Tim Bray proposed recently) is clearly be a big advantage as it can help locate the relevant context.

As it turns out the ontology proposed above is pretty much isomorphic with what Richard Newman came up with a few years ago in Tag ontology, and we should certainly try to work what is happening at the Tag Commons[1].

Richard Newman points out that a Tag has many of the properties of a skos concept. Things that are tags could therefore also be skos:Concepts, giving us a handy and simple vocabulary for relating tags.

With the above frameworks it should be possible to import tags from any of the tag engines such as del.icio.us and keep the meanings of the labels used in those tag engines separated enough to be able to go back to the context of the tagging, yet close enough together to be able to do searches across tag engines on the labels, as I showed in Folksonomies Ontologies and Atom[2]. This is really important for intranet tagging engines, as people do not want to duplicate the tagging work they do at home when at work.

Conclusion

Bookmarking is a necessary activity for information gatherers to keep track of content of interest to them. Tagging one's bookmarks is important tool to help find them again. The energy required in keeping this information can be gathered to help build enterprise encyclopedias in a distributed fashion: these are also known as wikis. These wikis can provide deep content an pointers of everything of interest to members of a group. Using Semantic Web technologies, it should be possible to build this in an open way.

Further thoughts

• How should the tag be related to the wiki page? Should the tag be given the url of a wiki page? Ie. should we have something like this:

  <http://france.sun.com/research/xyz.pdf> :tagedWith [ :tag <http://en.wikipedia.org/wiki/Company>, 
                                                                 <http://wiki.sun.com/emea>;
                                   :by [ foaf:mbox <mailto:henry.story@sun.com> ];
                                   :date "2007-02-03..."^^xsd:dateTime ].
  <http://en.wikipedia.org/wiki/Company> a :WikiPage, skos:Concept, :Tag;
                                            :scheme <http://en.wikipedia.org/wiki/>.
  <http://wiki.sun.com/emea> a :WikiPage, skos:Concept, :Tag;
                                   :scheme <http://wiki.sun.com/>.
  

  Or should there be a rdfs:seeAlso relation from the tag to the wiki page?
• If a tagging is an association of a tag with an object, would it be useful to give the user some more granularity as to what the type of the relation is? Or are we going beyond tagging here? It would also mean that one could have to limit the number of tags in a tagging event to one.
• Any other problems?

[1]Thanks Danny for rectifying my initial error. I thought Tom Gruber had been responsible for the rdf ontology. That was in fact Richard Newman. Tom Gruber has done a lot of work in helping people see the relation between ontologies and folksonomies and owns the Tag Commons site.
[2]Richard Newman also notes a very interesting parallel between a Tag and an RSS1.0 item. This is not surprising. The Evolution described earlier from bookmarking has been taken once before. Blogging stands for Bookmark Logging, and the various formats of RSS and Atom are just formats for describing bookmarks. These evolved over time to a system for describing not just information about a resource, but also be itself the new information resource. So we should not be surprised to find some very close commonalities between the syndication data models and what is needed for describing a Tag.
I found a similar parallel for Atom. An Atom Entry is very reminiscent of a tagging. An Entry is an event of changing something to a resource at the updated time, which is initiated by an author, to which one can associate a category which is isomorphic with a Tag. The structure of an Atom Entry is a little heavier though as it forces one to give the event a URI (the id) and some content.

Posted at 01:10PM Feb 06, 2007 [permalink/trackback] by Henry Story in SemWeb  |  Comments[0]

Web n+1

Peter Reiser who is in charge of a lot of cool new fangled internal web stuff at Sun has just coined a new term, Web n+1 to cover Web 2.0, Web 3.0 and all the future iterations. It's a fast moving target. So let's just always be one step ahead. :-)

Posted at 05:01AM Dec 12, 2006 [permalink/trackback] by Henry Story in SemWeb  |  Comments[0]