After some delay, we are pleased to finally release the UMBEL Web services endpoints to the public. We have re-organized the Web services we introduced three months ago to add coherency and flexibility to the model.

The goal remains the same, but with a different flavor: these tools let ontologists and Web developers search, discover and use the UMBEL subject concept and named entity structures. The added flavor is that these Web services now fully embrace the HTTP 1.1 protocol and are provided via a series of well established data and serialization formats.

We now have RESTful Web services to add to our RESTful linked data. Pretty cool combination!

We are introducing two kinds of Web services: (1) atomic Web services and (2) compound Web services. An atomic Web service only performs one action: It takes some inputs and then outputs a resultset of the action. A compound Web service takes multiple atomic Web services, plugs them together in a pipeline model, and then takes some inputs and outputs a resultset arising from the compound action.

The communication between each of these Web service instances and the external World is the same: communication is governed by the HTTP 1.1 protocol. HTTP is generally RESTful and used to establish the communication, to determine mime type and serialization, to get inputs, to return status of the communication and possible errors, and to send back the resultset of the computation of the Web service.

That way, we can easily, within hours, programmatically pipeline these atomic Web services together to create new Web services. We can integrate external Web services endpoints into the same pipeline without modifying anything to the architecture. Status, errors and resultsets are propagated along the line, directly to the data consumer. This is the flexibility part of the story.

Now, how cool is that?

Overview of the UMBEL Web Services Endpoints

We are today releasing a couple of these atomic and compound Web service endpoints to the public, but others will follow in the coming weeks and months. Four families of Web services have been released that total seven Web service endpoints:

• Finder
  • Subject Concept Test it; About; API Documentation ]
  • Named Entity [ Test it; About; API Documentation ]
• Reporter
  • Subject Concept [ Test it; About; API Documentation ]
  • Named Entity [ Test it; About; API Documentation ]
• Inference
  • Lister [ Test it; About; API Documentation ]
  • Validator [ Test it; About; API Documentation ]
• SPARQL [ Test it; About; API Documentation ]

If you don’t know what UMBEL is, I would suggest you read a background information page that talks about the project.

The most important reading related to this blog post is the API philosophy documentation page that talks about the details of the design of this Web services architecture.

For Web developers that want to integrate these Web services endpoints within their application, an API documentation page explains how to communicate with these endpoints for each of the services.

Example of an Atomic Web Service

The Inference: Lister Web service is a good example of an atomic Web service. It takes a subject concept URI as the input and outputs a series of super-class-of, sub-class-of or equivalent-class-of classes for that concept. As an atomic service it does one thing and one thing only: Inferring relationships of a given subject concept URI.

Example of a Compound Web Service

The Reporter: Named Entity Web service is a good example of a compound Web service. This Web service displays full of information about a UMBEL named entity URI. However, not all the information returned by this Web service is directly computed by it. In fact, the information about broader and equivalent classes and subject concepts come from the Inference: Lister Web service. Results coming from this Web service are immediately integrated in the Reporter’s resultset. This is easily done considering that they share the same communication language (HTTP 1.1) and the same data and serialization formats (XML, RDF+XML and RDF+N3). This flexibility is priceless to quickly create resourceful compound Web services.

Conclusion

After some months to get the design right, we have finally released some of the UMBEL Web services to the public. These Web services can easily be integrated in current software architectures to leverage UMBEL’s vision of the World. The architecture underlying what we have released today will help to easily integrate UMBEL’s principles and concepts within new and existing projects. This will ultimately help people to quickly react to the changing World of needs and expectations of data users and consumers.

I hope you will enjoy using these new Web services, which Zitgist is freely hosting. The data you get from the Web service is open data and can be used freely with attribution.

Please do report any issues you may encounter. We also welcome any advice or suggestions that you would care to provide to enhance the overall system.

I am really proud to announce the first public release of the UMBEL Ontology and its subject structure after one year of hard work with Mike.

As UMBEL is introduced in the UMBEL Technical Documentation:

“UMBEL (Upper-level Mapping and Binding Exchange Layer) is a lightweight ontology for relating external ontologies and their classes to UMBEL subject concepts. UMBEL subject concepts are conceptually related together using the SKOS and the OWL-Full ontologies. They form a structural ‘backbone’ comprised of subject concepts and their semantic relationships. By linking external ontologies to this conceptual structure, we explode the domain of the linked classes by leveraging this conceptual structure.

UMBEL defines “subject concepts” as a distinct subset of the more broadly understood concept such as used in the SKOS/OWL-Full controlled vocabulary, conceptual graphs, formal concept analysis or the very general concepts common to many upper ontologies. We define subject concepts as a special kind of concept: namely, ones that are concrete, subject-related and non-abstract.

UMBEL contrasts subject concepts with abstract concepts and with named entities. Abstract concepts represent abstract or ephemeral notions such as truth, beauty, evil or justice, or are thought constructs useful to organizing or categorizing things but are not readily seen in the experiential world. Named entities are the real things or instances in the world that are themselves natural and notable class members of subject concepts. More detailed distinctions are provided under Terminology and Definitions below.”

Mike Bergman wrote a really good introduction blog post about UMBEL that lists all the supporting material and services that exists to get starting with UMBEL.

In this blog post I will write about one example that shows how to leverage UMBEL in two different ways: (1) how to use UMBEL to “explode the domain” of an existing ontology and (2) how to use UMBEL when an ontology doesn’t exist to describe a certain domain. I will also write other blog posts in the coming days to show more ways to leverage UMBEL in different settings and how to use it to solve other kind of real world problems.

Some of this new material will begin to hint at Zitgist’s own plans for using UMBEL.

Linking FOAF to UMBEL to explode its domain

How many times have people tried to use FOAF to describe organizational entities? In the end, everything ends up being assigned to foaf:Organization. A company, a NGO, or any other kind of organizations were all foaf:Organization(s) or foaf:Group(s). In most cases the result was unsatisfactory and everything ended up being the same “classification”.

But I don’t want to describe a business as an “Organization”, or a NGO as another “Organization”. They are two quite different concepts, even if the upper concept that links them is an “Organization”. However, there are no ontologies (that I know of) that describe businesses and NGOs; and FOAF is not expressive enough to do that distinction. However, is it FOAF’s goal to be that expressive? Possibly; but not in its current state. So what we want here is to extend it: to explode its domain!

And, it is what we will do with UMBEL.

The goal is to link FOAF classes to UMBEL subject concepts so that we can extend FOAF’s classes with more general and more specific concepts such as Business and NGO.

If you take a look at how the FOAF ontology has been linked to UMBEL, you will notice that a foaf:Organization is equivalent to an sc:Organization. Note: the linkage of external ontologies classes is consistent within UMBEL. It is UMBEL’s view of the World.

Let’s take an example to show what I mean. What I want is to describe the Zitgist LLC business; to describe it as a business, and not an organization. However I want to be able to re-use properties described in other ontologies to describe this business. So, here is an example of how I can describe this company using a UMBEL subject concept and external ontologies properties:

<http://zitgist.com/about/> a sc:Business ;

foaf:name “Zitgist LLC.” ;

foaf:birthday “2006-10-20″ ;

foaf:logo <http://zitgist.com/imgs/zitgistlogo2_110_55.gif> ;

foaf:fundedBy <http://www.openlinksw.com> ;

bio:olb “”"Zitgist provides quality Linked Data products and services. Linked Data is based on open standards to interconnect any form of relevant information on demand and in context. Zitgist’s capabilities range from the consumer Web plug-in zLinks to enterprise linked data transformation and deployment. Our expertise spans from data, standards and protocols to tools, user interface design, and scalable architectures. Zitgist innovation helps make the connections that matter. Let us show you how our approach to Linked Data can bring the power of the network effect to your data assets and global information.”"”@en ;

foaf:based_near [ geo:Point [geo:lat "42.455", geo:long "-71.218"] ] ;

foaf:homepage <http://zitgist.com> ;

foaf:made <http://umbel.org/about/> ;

foaf:made <http://browser.zitgist.com/about/> ;

foaf:made <http://pingthesemanticweb.com/about/> ;

foaf:made <http://musicontology.com/about/> ;

foaf:made <http://bibliontology.com/about/> ;

foaf:made <http://talkdigger.com/about/> .

As you can notice with this example, Zitgist is defined as a sc:Business. Well, you are probably wondering what is a sc:Business? Let’s take a look at the subject concept’s detailed report: sc:Business.

The next question is: why can I use all these properties to describe a sc:Business? The quick answer is because foaf:Organization is linked (equivalent to) sc:Organization and that sc:Business is a sub class of sc:Organization. You can read the proof here; and check the figure below that shows the inference path that leads us to this result.

(Note: this is what we refer to: exploding the domain of FOAF)

Analyzing a SC with the Detailed Report

The Detailed Report web service tool helps users to check which external class is linked to which subject concept and the nature of the linkage. Additionally it helps people to know what properties can be re-used to describe an individual of that class. Here is a quick overview of what information can be accessed when using this detailed report tool. Let’s take the sc:Business detailed report page:

Named Entities

The Named Entities section lists a couple of named entities that belong to this subject concept class. These are direct, or inferred, Yago named entities that belongs to this subject concept.

More General External Classes
The More General External Classes section lists the external super-classes linked to this subject concept. So we can quickly notice that a sc:Business is a foaf:Organization, a foaf:Group and a foaf:Agent.

In-domain-of and In-range-of
The in-domain-of and in-range-of sections list the properties, defined in some external ontologies, that can be used to describe that subject concept. So most of the properties that I used to describe the Zitgist business above should appear in this list (except if the ontology hasn’t yet been linked to UMBEL; but a dozen are already so as shown in Appendix A of the main technical document).

More General and Specific Subject Concepts

The More General Subject Concepts and the More Specific Subject Concepts sections list the super-concepts and the sub-concepts of the current subject concept (sc:Business in that case). So, we can use UMBEL to describe an even more specific kind of business, for example: an Airline Company. Or we can use UMBEL to describe a more general kind of business: a Commercial Organization.

Finally this Detailed Report Web Service helps people to put a given subject concept into context: how it is related to external ontologies classes; how we can use properties to describe individual of these concepts; how is it related to other subject concepts? It is the tool to answer these questions.

Conclusion

In this blog post we saw how external ontologies classes can be linked to UMBEL to explode their domain: so to enhance their expressiveness. Additionally we saw how to use UMBEL web services to analyze a subject concept and to see its relations with other subject concepts, external classes and properties.

However this is just the beginning of our exploration of UMBEL. Many things are waiting for us at the corner. I am starting to write a series of blog posts that will show you different uses and characteristics of UMBEL. All of them will be explained using real world use cases and challenges. We will see how named entities are related to UMBEL subject concepts. We will see how named entities data sources such as Yago and the John Peel Sessions have been linked to UMBEL. We will see how the UMBEL Vocabulary can help people to describe subject relationship between: a RDFS class that can be linked to a subject concept (using umbel:isAligned and owl:equivalentClass); a named entity to a subject concept (using umbel:isAbout and umbel:linksEntity); and a named entity to another named entity (using umbel:isLike and owl:sameAs).

As you can notice, this is just the beginning. In meantime you can read the technical documentation to have a better understanding of UMBEL. And additionally you can read all the volumes that have been written to explain UMBEL’s evolution and the steps that lead to the creation of this of this first public release of the ontology.

Finally, you can now start using UMBEL in your own applications.  I would suggest you to revisit the UMBEL web services by reading my previous blog post: Exploding the Domain: UMBEL Web Services by Zitgist. Additionally I would suggest you to try to dereference subject concepts URIs such as: http://umbel.org/ns/sc/Project and http://umbel.org/ns/sc/Organization. All UMBEL Vocabulary’s classes and properties are dereferencable. All UMBEL named entities are also dereferencable along with all subject and abstract concepts.

Enjoy!

Mike Bergman just published a really good blog post that describes Zitgist’s definition of Linked Data. Zitgist define Linked Data has:

Linked Data is a set of best practices for publishing and deploying instance and class data using the RDF data model, naming the data objects using uniform resource identifiers (URIs), and exposing the data for access via the HTTP protocol, while emphasizing data interconnections, interrelationships and context useful to both humans and machine agents.

Mike explains this definition in 15 steps. One thing he stressed, and that I want to emphasis too is: Linked Data != Linked Open Data. Linked Data is not necessarily “open” in the sense of Open Source software and the freeware movement. Linked Data is about what we defined above. Enterprises can privately exchange data with business partners and clients. Enterprises can even do linked data between divisions of the company. Linked Data can be open, but is not limited to. Linked Data can be freely published on the Web; but Linked Data can also be published over private networks for limited use.

I am pleased to announce the first phase of the public release of the UMBEL Web Services by Zitgist. This first release consists of a series of user interfaces in-front of several UMBEL web services.

This blog post shows and explains what these web services are about and how people will be able to use them to leverage UMBEL to create new ontologies, to instantiate new data sets and to interlink external ontologies to explode their domains.

Background

For the last four to six months we have been in the process of creating the UMBEL ontology. We have been doing research to find the best basis datasets; we have been cleaning these datasets for UMBEL’s purposes; and we have been developing the ontology and its principles. Starting today, we begin the release process for UMBEL:

1. UMBEL web services’ user interfaces
2. UMBEL ontology (OWL-Full)
3. UMBEL ontology technical documentation
4. UMBEL subject concepts’ structure (SKOS + OWL-Full) & named entities instantiation
5. UMBEL web services endpoints.

UMBEL Ontology & Subject Concept Structure

Before starting to show and explain the UMBEL web services’ user interfaces’, I have to give some background information about the UMBEL ontology’s principles, and how the subject concept structure has been created. All this information will be discussed and explained at length in the UMBEL ontology technical documentation that is about to be published; but I have to give some technical background information in order to explain what these web services are about.

As described by Mike, UMBEL’s purposes are:

“[...] to provide a lightweight structure of subject concepts as a reference to what Web content or data “is about”, what is called a concept schema in SKOS [...]

Think of the backbone as a set of roadsigns to help find related content. UMBEL is like a map of an interstate highway system, a way of getting from one big place to another. Once in the right vicinity, other maps (or ontologies), more akin to detailed street maps, are then necessary to get to specific locations or street addresses.

By definition, these more fine-grained maps are beyond UMBEL’s scope. But UMBEL can help provide the context for placing such detailed maps in relation to one another and in relation to the Big Picture of what related content is about.

These subject concepts also provide the mapping points for the many, many thousands (indeed, millions) of specific named entities that are the notable instances of these subject concepts. Examples might include the names of specific physicists, cities in a country, or a listing of financial stock exchanges. UMBEL mappings enable us to link a given named entity to the various subject classes of which it is a member.

And, because of relationships amongst subject concepts in the backbone, we can also relate that entity to other related entities and concepts. The UMBEL backbone traces the major pathways through the content graph of the Web. For some visualizations of this subject graph, see So, What Might The Web’s Subject Backbone Look Like?”

A four-article introduction to UMBEL can be read from Mike’s blog at:

• Part 1: A Re-Introduction to UMBEL
• Part 2: UMBEL: Making Linked Data Classy
• Part 3: Subject Concepts and Named Entities and
• Part 4: Basing UMBEL’s Backbone on OpenCyc

UMBEL is a 21 000 subject concept structure that has been derived from the OpenCyc ontology. The structure is described in SKOS and OWL-Full. Each concept is an invididual of the skos:Concept class, which are themselves OWL classes. This dichotomy is the basis of UMBEL. Since the subject concepts are classes, this mean that we can relate these classes to external ontology classes using properties such as rdfs:subClassOf and owl:equivalentClass.

So what does all of this mean? It means that once the linkages between UMBEL subject concepts and external ontologies classes are made, the following becomes possible: 1) the UMBEL subject concept structure can be used to describe (instantiate) things using the UMBEL data structure; 2) external ontology properties can be re-used to describe these new instances since external ontologies classes are linked to UMBEL subject concept classes; and 3) in some cases, the properties defined in these ontologies can be used in relation with UMBEL subject concept classes. The forthcoming technical documentation about this stuff will provide more detailed explanation. For the moment, just accept these assertions as being true.

The UMBEL web services (user interfaces) have been created to help people to manage these relationships between UMBEL subject concepts classes and external ontology classes. People will use the services to infer facts from the structure of the subject concepts, to check if a class is a sub-class, a super-class or an equivalent class of another class. They will also use the services to see what properties, defined in external ontologies, can be re-used, and on which subject concept.

Let the show begin!

UMBEL Web Services Index Page

The entry page lists all the available web services. For each web service, you have a link to the web service user interface, a link to an about page explaining the basis of the web service, and a link to the technical documentation of the web service endpoint: how to communicate with the endpoint web server and how to interpret the answer sent by the web service.

Take note that the web service endpoints are not yet publicly available, and that this endpoint page is provided now for information purposes.

Eleven UMBEL Web Services

1. Find Subject Concepts
2. Subject Concept Report
3. Subject Concept Detailed Report
4. List Sub-Concepts & Sub-Classes
5. List Super-Concepts & Super-Classes
6. List Equivalent External Classes
7. Verify Sub-Class Relationship
8. Verify Super-Class Relationship
9. Verify Equivalent Class Relationship
10. Subject Concepts Explorer
11. Yago Ontology — a little help from our friends.

Searching the UMBEL Subject Concept Structure

The first thing people will want to do is to search within the UMBEL subject concept structure. The “Find Subject Concepts” web service helps people to locate potential subject concept they are looking for.

If someone looks at the Find Subject Concepts page and performs a search for the keyword “project”, he will get this list of subject concepts:

Note: all subject concepts are ordered alphabetically and the search has been performed on the subject concept label and their semsets (and not in their definition).

The “finding” web service along with all the inferencing web services use the same result page layout: you have a list of subject concepts with their human readable definition (note: 8000 definitions out of 21 000 have yet to be created). If a user clicks on a result, he will be redirected to the Report and the Detailed Report user interfaces. Additionally, a user can click on the small “earth” icon to start browsing the surrounding subject concepts nodes in the Explorer visualization tool.

Inferencing the UMBEL Subject Concept Structure

A series of web services has been created to infer facts in the UMBEL subject concept structure. There are the two main categories of inferencing web services:

1. The ones that list subject concepts that are more general, more specific or equivalent to a given subject concept
2. The ones that answer the question: is this subject concept a sub-concept, a super-concept or an equivalent concept to this other subject concept?

These web services can be used not only to infer these facts on UMBEL subject concepts, but also on external ontology classes. There are a couple of examples of what can be done with these inferencing web services:

• Give me the list of more general subject concepts (super-concepts) of the subject concept “project”
• Give me the list of more specific subject concepts (sub-concepts) of the subject concept “project”
• Give me the list of external ontologies classes that are equivalent to the subject concept “project”
• Is the “project” subject concept a super-concept (a more general concept) than the “campaign” subject concept?
• Is the “campaign” subject concept a sub-concept (a more specific concept) than the “project” subject concept?
• Is the “project” subject concept equivalent to the “foaf:Project” external ontology class?

Note: some people may notice that the doap:Project external ontology class is a sub-class of the “Project” subject concept. This is not intuitive for humans, but this situation will be explained at length in the UMBEL Ontology Technical Documentation. To make a long story short: considering the nature of the current definition of the doap:Project class, we couldn’t say that it is equivalent to the “Project” UMBEL subject concept.

Visualizing the UMBEL Subject Concept Structure

While inferencing and lookup are good, we still have some issues when we try to “feel” what the UMBEL subject concept structure is. The following two user interfaces will do their best to help people visualizing the subject concepts description and their relations with other subject concepts and external ontologies classes.

Lets start with a wonderful visualization tool, created by Moritz Stefaner, and used by UMBEL to let people visualizing and browsing the data structure.

Lets start by browsing the relationship of the “Project” subject concept:

You can navigate from one node to another by clicking any of the circles. Each circle is an UMBEL subject concept or an external ontology class.

When a node is selected, its concept description is displayed in the right sidebar of the interface.

Note there are four different kinds of relationship between the concepts:

• Blue (B). (concept A) — broader than –> (Concept B). concept A is more general than concept B
• Red (N). (concept A) — narrower than –> (Concept B). concept A is more specific than concept B
• Green (=). (concept A) — equivalent to –> (Concept B). concept A is equivalent to concept B
• Mauve (I). (concept A) — is a –> (Concept B). concept A is an instance of the concept B

As each node is selected, the display refreshes and shows the new set of relationships for the current node (subject concept or external class). Note the dropdown list shown at the upper right of the display enables you to return to previous views or steps.

The Detailed Subject Concept Report

The detailed subject concept report is the tool to know everything about a specific subject concept. This is not really a web service, but a user interface that uses all existing UMBEL web services to display a detailed report of a subject concept, and all its relations with other UMBEL subject concepts and external ontology classes and properties.

There is the detailed report of the “Project” subject concept:

There is the list of information available from that detailed report page:

• UMBEL Subject Concept Name - the name of the subject concept
• Semset - the preferred label and its alternative labels used to refer to this concept. The alternative labels are aliases, synonyms, collocations, etc.; related to the preferred label of the subject concept
• Definition - the human readable definition of the subject concept
• Equivalent External Classes - the classes from external ontologies that refer to this same subject concept. Note that the UMBEL Ontology Technical Documentation will explain how the equivalence relation between an external ontology class and an UMBEL subject concept is done
• Named Entities - a list of named entities related to this UMBEL subject concept. Most of the time, the subject concept has the “type of” characteristic for these named entities. For example, for the subject concept “Person”, “Albert Einstein” is of type “Person”. The first named entities data set that has been used to create this list of named entities is Yago (more about this below).
• More General External Classes - these are the classes from external ontologies that refer to a more general concept. Note that the UMBEL Ontology Technical Documentation will explain how the super-class relation between an external ontology class and an UMBEL subject concept is done
• More Specific External Classes - these are the classes from external ontologies that refer to a more specific concept. Note that the UMBEL Ontology Technical Documentation will explain how the sub-class relation between an external ontology class and an UMBEL subject concept is done
• In-domain-of - this is a list of properties defined in external ontologies where an individual of the UMBEL subject concept class can be used in the domain of the property. For example, for the subject concept “Person” the in-domain-of property: “foaf:interest (domain: foaf:Person)” means that an individual of the class umbel:Project can re-use the property foaf:interest that is defined in the FOAF ontology in its domain (<umbel:Person> <foaf:internet> <…>). Note that the UMBEL Ontology Technical Documentation will explain how the in-domain-of relation between an external ontology class and an UMBEL subject concept is done
• In-range-of - this is a list of properties defined in external ontologies where an individual of the UMBEL subject concept class can be used in the range of the property. For example, for the subject concept “Person” the in-range-of property: “doap:developer (range: foaf:Person)” means that an individual of the class umbel:Project can re-use the property doap:developer that is defined in the DOAP ontology in its range (<…> <doap:developer> <umbel:Person>). Note that the UMBEL Ontology Technical Documentation will explain how the in-range-of relation between an external ontology class and an UMBEL subject concept is done
• More General Subject Concepts - this is the list of more general internal UMBEL subject concepts related to the concept
• More Specific Subject Concepts - this is the list of more specific internal UMBEL subject concepts related to the concept.

As you can notice, all the relations between any UMBEL subject concept to other subject concepts or external ontologies classes and properties is shown in this detailed report page.

This detailed report page was created not only to show people what UMBEL subject concepts are. I envision that people (more specifically ontologies developer & ontologies users) will also use it to check the current linkage between UMBEL and external ontologies and how to use UMBEL to instantiate and describe resources in RDF, etc. The UMBEL ontology documentation will describe some linkage and re-using use cases in further detail.

Linked External Ontologies and Named Entities

Lets take a deeper look at the named entities section of the detailed report of the “Person” subject concept:

These named entities are individuals belonging to the class umbel:Person. If you click on one of these person names, you will notice that they are described the Yago data set. How is this possible?

To make another long story short: umbel:Person is an equivalent class to the cyc:Person class; cyc:Person is an equivalent class to the wordnet:Person class; yago:R._B._Bennett is an individual belonging to the same wordnet:Person class. So we can infer that yago:R._B._Bennett is an individual also belonging to the umbel:Person class. However, these technical details will be explained at length in the UMBEL ontology documentation.

But the truth is that this is not the most wonderful thing around. The most wonderful thing is when we understand what that really means (the linkage between yago:R._B._Bennett and umbel:Person (or any other data sets linked to UMBEL)). This means that this linkage is literally exploding the domain of each of these linked named entities. In fact, now we know this about yago:R._B._Bennett:

• It is an umbel:Person
• It is a cyc:Person
• It is a foaf:Person & a foaf:Agent
• It is a umbel:HomoSapiens
• It is a umbel:SocialBeing
• That we can re-use the foaf:birthday, foaf:name, doap:translator, dcterms:creator, etc.; external ontologies properties to describe this person.

We can infer all these things, and much more, about yago:R._B._Bennett only by linking it to UMBEL. We just contextualized it; and then we exploded its domain!

This is what UMBEL is about; this is the value it creates; and its contribution to the Semantic Web.

Conclusion

This is just the beginning of UMBEL. Currently ten external ontologies have been linked to UMBEL. The attentive eye will notice some strange results in the in-domain-of and in-range-of detailed report sections. More work has to be put in the linkage; however as you will notice in the technical documentation of UMBEL, some weird results come from the way some ontologies are defined. So, these ontologies self-definition create some of these weird results. So this mean that these UMBEL tools won’t only help by linking external ontologies, but they will also help to define new ontologies and to fix existing ones.

Stay tuned; more stuff will be released in the coming weeks and months.

I am pleased to finally be able to say that Mike Bergman is the new Chief Executive Officer of Zitgist LLC. After months of discussions, hard work, planning and development, Mike became officially the new CEO and Zitgist made a giant leap ahead.

The first contact

The first time I started to collaborate with Mike was related to the UMBEL project. Mike had an idea and I wanted to help him to make it real. At that time I didn’t know that my participation in UMBEL and my collaboration with Mike would impact Zitgist forever.

Months later I released a new prototype project called zLinks. This project has been the tipping point of my collaboration with Mike. However, even at that time, I didn’t know how these two projects would change Zitgist forever.

Those first months were a warm-up session for Mike and me. Everything started from there; we were ready to work together.

Working together

Since that time we have worked together to forge Zitgist, to shape it to Kingsley‘s, Mike’s and my vision. The process hasn’t always been easy. Each day brings its challenges, opportunities and work. We spent months to talk about Zitgist’s vision, voice, goals and direction.

Considering Zitgist’s business, people could think that everything was related to technologies, high-tech research and development. But today I would say that those things are nearly secondary. It is sure that activities, services and products are at the center of our discussions; however, we found that the center of everything was: communication.

Communication

Mike lives in Iowa, Kingsley in Boston, me in Quebec City. The three of us have different cultures, different native languages, and live in different places.

On the other hand, Zitgist is a company that gives services and creates products to help people and businesses interlink their data: to make real the value of the global data assets. We try to make data easier to communicate, publish and share.

We belong to the semantic web community. We talk and collaborate with people from around the World: with different cultures and languages. We talk about a domain (the semantic web) that is not yet fully defined and that is still highly academic. We are still juggling with concepts and terminology that we try to share with the community and people from outside this community.

Given that, all challenges can be captured in one word: communication.

We have to communicate our ideas and vision; we have to sell our services and products; we have to make data richer and easier to use and understand; we have to create a vision, a voice and a language. So yes, this is all about communication. But even more: it is all about human communication; communicating to people and companies in different languages with different cultures.

We understand one aspect of the semantic web vision as machines talking to machines. But Zitgist’s challenge is to talk with people.

Mike is now the new orchestrator of Zitgist; it is time for us to communicate our voice to the World.

A new Zitgist

This process forged Zitgist. All the discussions we had, all the ideas we challenged and all the ways we experimented to speak with the outside World forged Zitgist’s vision and voice. The time we put into making Mike the new CEO completely changed Zitgist’s dynamic. We were not just talking about hiring someone; we were talking about growing up a business and achieving a shared vision and voice. Once more, it was about communicating ideas, concepts and vision.

It is all about communication.

Thanks for joining us, Mike.

More references about this news

The official press release
Mike’s personal perspective

Zitgist is releasing a totally new semantic Web data viewer: the Zitgist DataViewer (on test servers). This new Web service pushes even further the semantic Web data visualization principles initiated with the Zitgist Browser.

The goal of the Zitgist DataViewer visualization tool is to provide a user interface that morphs semantic Web data into a form that can be easily read and understood by humans. The Zitgist DataViewer moves this vision forward in three ways by:

1. Adding features to help users manage the overload of information published from some data sources,
2. Speeding up the data visualization process and giving more feedback to users when data sources are being analyzed and documents constructed, and
3. Changing the templating system to make them cope with a wider range of type entities even if these types are unknown by the system.

In this blog post I will show you all the new features of the Zitgist DataViewer, how it can be used, and how each feature enhances the experience of users.

Main Entity Display Sections

On the semantic Web, everything is a "resource". A resource can be seen as an Entity, or sometimes also called a Thing. This thing can be a person, an album, a place in the World, etc. Each entity is described by its properties: the age of a person, the name of an album, the population of a city, etc.

The Zitgist DataViewer reads all the information available for these entities, and displays it to the user as best as it can so that users can easily read and understand information about these various entities.

The first step performed by the Zitgist DataViewer is to get information about that entity and to create the Web page that will be presented to users. Figure 1 is the progress bar showing the status of the Web page creation process to the user.

1. Tab. This tab displays the type of the entity. In this case, Ivan is a Person. If the table is collapsed (see section about tools), the name of the entity will be displayed in the tab instead of the type.
2. General information. This section displays general information about an entity. In this example, since the entity is a person, the name of that person, his contact information, his location and a photo of the person are displayed in the "general information section".
3. Tools. These tools are used to perform action on an entity table.
4. See-more. This section aggregates all the same properties describing a person. By clicking on the "see-more" button, the complete list of properties will be displayed to the user. This feature gives an additional means for users to manage information overload.
5. References. This section lists all other entities referring to the viewed entity. For example, in this case the references are each entity that "knows" Ivan, such as friends, co-workers, etc.
6. Information sources. This section displays clickable links to the locations of all Web sites that contributed the actual information displayed in the DataViewer.

Note – depending on the specific type of Entity at hand – there are multiple display formats or "templates" (see below) that structure the content and format of the actual data presentation within the DataViewer.

The General Information Section

Figure 3

This section displays all general information about an entity. General information is typically the information a human would think best describes a particular type of entity. For example, typical information about a person would be name, contact information, location, birthdate, occupation, photo, etc.

Tools

Figure 4

These tools shown in the red box are used to perform some actions on the entity table. From the left, the icons do the following:

• mini-Z icon. This displays information available from zLinks about the entity.
• Lookup icon. This shifts the focus of the DataViewer to this particular entity. In some cases you may have more than one entity per URI, or you may want to focus your navigation on an embedded entity, and this tool allows you to only see the currently active entity.
• Up arrow icon. This scrolls the DataViewer up to the page from any entity table.
• Close icon. This collapses any entity table. By clicking on this icon, only the tab becomes apparent.

See-more

This feature is used to aggregate and hide all same properties. As shown in Figure 5, if the user clicks on the blue button that says that there are 70 more "Knows" properties, then all known properties will be displayed to the user.

Figure 5

On the other hand, if the user check clicks on the "Hide objects" button, this expanded display is then collapsed with the section hidden again.

Inline Embedding

With the Zitgist Dataviewer, users have the possibility to embed entities on-the-spot. This means that they don't have to open a link in another page; they can do it by embedding it in the current page.

If the user moves his mouse over a link within an entity table, he will see a blue right-arrow appearing. If the user clicks on the normal link (using the example of Uldis Bojars in Figure 6), then the entity Uldis Bojars will be opened in a new page.

On the other hand, if the user clicks on the blue right-array, the Uldis Bojars entity will be embedded on-the-spot.

Figure 6

If the user click on the arrow, a progress bar will shows the processing, by the server, of the creation of the Uldis Bojars entity.

Figure 7

This action results in the entity Uldis Bojars being embedded in the current DataViewer page as shown in Figure 8.

Figure 8

References

On the semantic Web, entities are more often then not referring to other entities. Such a situation arises when I describe the fact that I know another person. So, an entity (me) knows another entity (say, Bob).

The references section of the Zitgist DataViewer thus shows the user what other entities refer to the current one being displayed.

In the Figure 9 we expand the references of the Ivan Herman entity. We now see the entities, known by the Zitgist DataViewer, that refer to the Ivan Herman entity. One reference we see is to Yves Raimond:

Figure9

Information Sources

On the semantic Web, everybody can describe anything about everything. This means that I can describe things about a person entity, or an album entity, or about virtually anything.

The only thing I have to do is to publish that information on the Web so that people can access it and do whatever they want with the information once published.

The information sources section of the Zitgist DataViewer is used to tell users where the information they are looking at comes from on the Web. So this section displays a link to all the Web pages where we got information about an entity that we display in the DataViewer.

This way, users can check the provenance (so accuracy and trust) of the information they are viewing.

Figure 10

Paging Tool

In some cases, there may be more than one resource to display to the user for a given data source. If there are more than five resources to display, results are paged. This is another feature to help the user to manage the overflow of information.

Figure 11

Since the pages are created asynchronously (using AJAX techniques), people also copy the link from their Web browser to send to others. To do so, the user simply clicks on the "link to this page" icon and then copies the URL.

Sidebar Tools

Another feature to manage information overload is the addition of sidebar tools:

Figure 12

The user can click on the first tab to display the "Navigator Sidebar Tool" or on the second tab to display the "Selector Sidebar Tool". Then he can re-click on these tabs to close and hide the sidebar.

Navigator Sidebar Tool

This tool (Figure 13) provides an overview of the entities available for a given data source. All entities are aggregated in the same section of the tool depending on their type (all persons together, all documents together, etc.). By clicking on one of these items the user is redirected to the table displaying information about the entity.

Figure 13

Selector Sidebar Tool

The Selector Sidebar Tool (Figure 14) is used to show and hide entities and properties to the user. By using this tool a user can hide things he doesn't want to see:

Figure 14

This tool can be really useful with some scenarios. For example, if a user only wants specific information from a given data source; then he only has to click on the "Hide all" button to hide all properties and then to click on the property he wants to see. This way, only the desired information will be displayed. In essence, the Selector works as a filtering or faceting mechanism.

The Templating System

The Zitgist DataViewer uses a templating system to organize the data available for a given entity. Depending on the type of an entity (is it a person? a music album? a document? a geographical place? etc.) the viewer will manage and organize the information available for an entity differently.

Each template tries to organize the information such that it is optimized for human reading and understanding.

By example, each template defines which information to put in the General Information section of each entity. It determines how to format and organize that information, how to handle specific things such as images, how to insert certain widgets such as maps and grids, and how to optimize the presentation of other kinds of information.

The only goal of the templates is to make information for each viewed entity more readable, so understandable, by humans.

The DataViewer's new templating system also manages some properties even if a template is not defined, resulting in a hierarchy of templates composed of sub-templates inherited from upper templates.

This means that even if the Zitgist DataViewer doesn't know how to organize information of a certain type of entity (because the viewer may not have a template for that type), it can organize other parts of the information based on existing templates and the behaviors of certain special properties.

Currently Supported Templates

There is the list of templates currently supported by the Zitgist DataViewer:

• Music Ontology templates:
  • mo:Release
  • mo:SoloMusicArtist
  • mo:Track
  • mo:MusicManifestation
  • mo:MusicArtist
  • mo:MusicGroup

Screenshots:

• Description Of A Project Ontology templates:
  • doap:Project
  • doap:Repository
  • doap:Version

Screenshot:

• Friend Of A Friend Ontology templates:
  • foaf:Agent
  • foaf:Document
  • foaf:Group
  • foaf:Image
  • foaf:OnlineAccount
  • foaf:Person

Screenshot:

• Geonames Ontology templates:
  • geonames:Feature

Screenshot:

• Semantically-Interlinked Online Communities Ontology templates:
  • sioc:User
  • sioc:Container
  • sioc:Forum
  • sioc:Item
  • sioc:Post
  • sioc:Site
  • sioc:Space
  • sioc:Usergroup

Other Ontologies also result in the addition of still more templates, for example: wgs84:Point, wps84:SpatialThing, bibo:Document, rss:Channel, rss:Image, rss:Item, frbr:Endeavour, frbr:Manifestation, rdf:Bag, rdf:Seq, owl:Thing.

One more screenshot (RSS):

The Skinning System

While the templates organize the structure and scope of information about entities, skins manage the appearance of that organized information. The Skinning System for the DataViewer governs which colors to use, which images to use, which dimensions to use, where to place on the screen, and what to show.

There are currently two skins created for the Zitgist DataViewer. The default skin is the standard appearance of the DataViewer within your Web browser. The second skin – called the mini-Dataviewer – is used to optimize the display of the DataViewer within a restricted area, such as a small container on a Web page or a mobile device such as the iPhone.

Figures 15 and 16 show two entities viewed with this mini-DataViewer interface on an iPhone. As you can see, the information is not displayed the same way, and the user interface and colors have changed to optimize for a small mobile device.

Figure 15

Figure 6

zLinks within the DataViewer

From earlier posts, recall:

“The zLinks client-side service is an entry point to a vast new world of additional rich data and link-related services [...] zLinks automatically ‘turbocharges' all of your existing and new content links to tap these resources that are contextual, relevant, informative and actionable."

The zLinks Web service has now been integrated within the Zitgist DataViewer.

Users now have access to related stuff about every linked entity displayed in the DataViewer. These zLinks provide not only related information about an entity, but also what that entity is about and what also refers to it.

In the Figure 17 we use the zLinks Web service to take a look at the publications (in this example, the talks) linked from the entity Ivan Herman. The service lists all talks by Ivan, as well as provides links to his personal profiles and to the profiles of his friends.

Figure 17

Dataviewing examples

There are a couple of visualization of URIs using the Zitgist DataViewer.

The default DataViewer user interface:

• Ivan Herman
• Dan Brickley
• Tim Berners-Lee
• Frederick Giasson
• SWAML
• zLinks
• Neocortex
• OpenLink Software Ltd.
• Zitgist LLC.
• British Dental Journal (RSS)
• Embrun
• Eiffel Tower
• New York
• Ganges River
• Confessions on a Dance Floor
• Geddy Lee
• Porcupine Tree

The mini-DataViewer user interface (you will be redirected to an iPhone testing website):

• Ivan Herman
• Dan Brickley
• Frederick Giasson
• SWAML
• zLinks
• Neocortex
• Zitgist LLC.
• British Dental Journal (RSS)
• Embrun
• Eiffel Tower
• New York
• Ganges River
• Confessions on a Dance Floor
• Geddy Lee
• Porcupine Tree

Conclusion

The Zitgist DataViewer is the next step to make semantic Web data more accessible and usable. It is an important upgrade over its earlier version, what had been known as the Zitgist Browser.

We are now learning how to move beyond the "triple" and how to better visualize semantic Web (RDF) information published on the Web. Many new features in the DataViewer help users to manage information overload. Others provide feedback or access to still further useful information. Performance and display speeds have been improved. Organization and a templating system add further flexibility.

We believe the usability of the DataViewer has been greatly enhanced. Still, we are not satisfied. We welcome your feedback and will continue to seek improvements for the next round of enhancements. Zitgist is committed to data usability and ease of access. We welcome your participation as we continue on this quest!

zLinks will turbocharge the links on your web pages. It will unveil the power of the connections you make.

The story goes like this:

The essence of the Web is the link. We use it to navigate, discover, form communities and get rankings on search engines. But, each link carries much more behind it than what has generally been exposed.

zLinks is a client-side service provided as a simple plug-in to turbocharge your links. All links embedded in a blog post or its comments, or from within a content management system (CMS), gain immense power to link to and display additional related data and information. zLinks thus becomes a jumping off point for additional exploration and learning.

Site authors merely install the free zLinks service plug-in and their users and readers gain the benefits thereafter.

A New Service and WordPress Plug-in

Three weeks ago I introduced the Zitgist Browser Linker. From the basis of this prototype we now have: created a new brand called zLinks; enhanced the underlying web service that powers it; and greatly enhanced the initial WordPress plug-in.

Some Basics

We should remember what zLinks does:

1. To visit Web pages and locations
2. To potentially take actions (say, buy or search), and
3. To retrieve data resources.

It is that simple.

So, what is really new with the new and improved zLinks, other than a cleaner and more usable user interface with its new icons, details, scroll bar and better linked resources results?

Annotations

With zLinks, we wanted to take a first step toward editing and publishing stuff on the Semantic Web. We wanted to let people annotate their embedded URLs with some thoughts, some remarks, etc.

Remember that I said, in my previous blog post about zLinks, that each URL is in fact a URI, potentially an identifier for a resource.

So, with the zLinks WordPress plug-in, people now have an easy-to-use tool to annotate resources from within their blog posts.

In two clicks one can say anything about any resource he links to from his blog post. Simple? Yeah it is (at least I hope it is).

Annotating resources is simple, however when we start thinking about what is going on under-the-hood, when we start thinking about the architecture used to publish this data and make it available on the Semantic Web, things start to get more complex (and, more fun ☺ ).

Publication Architecture behind zLinks Annotations

First of all, zLinks archives all annotations on the local instance that is running WordPress (in the case of the WordPress plug-in). Then, if the author chooses to share his annotations, then they can be made available in RDF, with dereferencable URIs, in multiple forms, using the Annotea ontology.

URIs Generated

Three kind of URIs are generated by zLinks:

• URI for the resource representing the author (note that this can change with preferences, more on this below)
  • Example: Plain RDF, Browser
• URI for the list of all annotations from a blog (will only list the annotations that are shared)
  • Example: Plain RDF, Browser
• URI for a single annotation
  • Example: Plain RDF, Browser

These generated documents are then used to publish the information to anyone who wants it.

Why Are the URIs Still Ugly?

The goal is make the installation of the plug-in as simple as possible and to make sure it is compatible with any WordPress installation. Since I didn't want people to have to mess with the configuration file of their web server or to create URL-rewrite rules such as the ones on the Apache server, we left the ugly URIs as is.

(But, stay tuned, everyone always prefers a pretty URI!)

Consuming Annotations Data

The first service that consumes the zLinks annotations data is Ping the Semantic Web. So, each time a new annotation is created or updated (and assuming that the author has chosen to share his annotations), zLinks will send a ping to PTSW so that still other services can be notified of this creation or updating.

The zLinks web service (which is what sends the links to the zLinks WordPress plug-in) communicates with PTSW to get the latest created and updated annotations. Once zLinks gets this list of annotations, it then indexes them in the Zitgist Linked Data Store.

Then, once indexed by the system, the annotations are processed by zLinks and further aggregated with other resources for other zLinks. So, if I annotate a URI A and if another author puts a zLink for this same URI A, then he will see my annotation, on his blog, for this specific embedded link.

More than Annotating a Web Page

This goes way beyond merely annotating a URL. In fact, I can annotate a URI referring to a resource describing a person. That way, I can say something about a person directly from my blog. So, I can annotate (say something) about a place I link to, about a person, about a book, about a music album… Amen!

(By the way, see the orange underline with those zLinks "mini-Z" icons? That means the link is annotated. Mouse over one of the icons to pull up the zLinks popup and its annotation. You can then see what I mean about the power of these annotations. And, yeah, there is also much else hiding behind the different icon types and backlinks you see in these popups! Go ahead, explore . . . )

The most beautiful part of the story is that the author only has to annotate a link using the zLinks easy-to-use interface, and all the other magic is done automatically, without any human interaction.

Links are made by themselves, data is published by the user's publishing software (WordPress), the data is broadcasted (multiplexed) to web services and user agents using PTSW, and the data is re-used by zLinks via ZLDS. Wow!

All in 2 user clicks! Can you say Cool?

How to Annotate a URL

As a blog author, if you are logged into your WordPress instance, you will see two icons instead of one when you are viewing the blog post you wrote.

(Note, only you as the author see these two icons; standard visitors do not.)

You only have to click on the first of the two icons to see the annotation window appearing beside the link. Then you fill in the annotation writing box and click the "Save" button.

That is it; it is that simple.

Configuration of zLinks

To gain this sharing power, the blog owner must do a simple configure of his zLinks plug-in. First, he has to determine if he wants to share his annotations with the World (the "public" option with notifications via PTSW, what I explained above), or if he wants to restrict his annotations as "private" so that only his blog readers can read them.

The other thing a user has to configure is the identifier he will use as the reference to himself as the annotations author.

There are three choices:

1. The author doesn't have an existing ID, and wants to use the default one provided by zLinks. With this option, zLinks assigns a simple numerical identifier generated by WordPress,
2. The author does have an existing ID (URI) and wants to use that as identifier. That way, his personal URI (usually the one he uses to refer to himself on the semantic web, such as his FOAF profile URI or OpenID), will be to one that links him as the author of his annotations, or
3. The author starts by using the default URI by zLinks (#1), but later wants to create a better personal URI (#2). In this case zLinks will create a special owl:sameAs link between the default profile and the new one so that once the personal URI is created all prior annotations get the good treatment too.

These simple things are the only ones a blog author has to configure to make the zLinks plug-in work as he would like. Much more information about these configuration options and other topics is available in the FAQ.

Must Read!

The best introduction you can read is from the home page of zLinks.

The best way to see how zLinks is working in its smallest detail is by reading the extensive FAQ. (Actually, even better is to install it!)

Some Use Case Examples

• music artist
• music album
• music track
• person
• organization
• product
• book
• city
• Annotea Ontology

Download

You can download from here and install zLinks in your WordPress software.

Conclusion

So, turbocharge your links on your blog to show the power of their connectivity to your blog readers.

This is an example of how semantic web technologies and concepts can be leveraged to add value to web services and to enhance users experience.

(By the way, I'd like to thank Mike Bergman for letting us use some of his text from his earlier blog review; and for revising this blog post grammar )

Every link has a relation on the Semantic Web. Each time a person create a link from a web page to another web page, it does much more than simply linking… In fact, the Web and the Semantic Web are starting to mesh together.

The meshing is occurring at the level of the URI, or more specifically at the level of the URL if we are talking about the Web. This is what I will show you in this post using a WordPress plug-in I developed using Zitgist technologies.

Motivations driving the development of the plug-in

The first objective of this project is to try to find out how people could integrate semantic web concepts and principles in the systems they daily use. How can we integrate the semantic web into Blogs for example? Is the use of semantic web technologies only good at publishing content in RDF? This is certainly one thing, but I doubt it is the only one. This is for that reason why I put some time in developing this prototype.

The second motivation is to create a good prototype of a system using Zitgist’s architecture to show people how they can take advantage of Zitgist to develop their projects; to make their vision a reality.

Some background thinking about the plug-in

On the Web, people mainly manipulate web page resources. They locate them on the Web using a unique locator, called a URL. On the semantic web on the other hand, people do not only manipulate documents; they manipulate many kind of Things, many kind of resources. They refer to them using URIs. The difference between a URI and a URL is that a URL is resolvable on the Web, but not necessarily a URI (in fact, a URI is the super-class of a URL). However, best practices suggest people to make URI resolvable (dereferencable) on the Web; in such a case a URI is a URL.

Anyway, all this to say that a URI in the semantic web can be a URL on the Web. There are many use cases emerging from that special digital environment. As an example, many people will use a Wikipedia Wiki Page URL as an URI for a topic, an interest, or for many other relations to these concepts. In such a case, the URL of a webpage is used to refer as a Concept. I don’t want to discuss about the basis of this, but it is a fact, and we have to handle it.

Introduction to the Zitgist WordPress Plug-in

This plug-in is quite simple in appearance, but has some really interesting results for users.

The only thing this plug-in does, is to show blog readers existing related data for a given URL and, in some case, to enable them to perform actions based on this data.

By example, if I make a link to Tim Berners-Lee‘s web page, a user could be interesting in having more information about Tim, directly from the article he is reading. Tim has many data related to him from the semantic web.

That is it. The plug-in display related information to links from a blog post. In this case, it is people Tim knows and Tim’s profile. The information is shown the users using a contextual menu. The data is requested to Zitgist’s systems and is displayed to the user. This is that simple, but how powerful?

The usefulness of the Zitgist WordPress Plug-in

The plug-in is quite useful in many ways. In fact, it instantly displays related information about a link to readers of the blog. From any blog post, a reader can easily jump to resources related to each link.

Some use cases

Above I said that a URL, a web link, could be much more than it usually appears. So bellow, I show a couple of use cases showing the potential behind the idea.

1. URL as a web page

What happen when a link from a blog post is a URL? Well, some things can happen, and there is an example:

Check it by yourself: The Bibliographic Ontology

Here a user can check the webpage directly, or he can jump to related resources. These related resources come from the semantic web. The first one is the description of the project. The following two are the authors of the ontology. The last resources are documents related to the ontology and the “version” of the ontology.

2. URL as a dereferencable URI

For the non-initiated readers, I would suggest you to read this best practice tutorial explaining how to publish semantic web data on the web.

Sometimes (okay, not that much at the moment, but I hope people will start), people link to resource URIs (so, URL that can be dereferenced to get RDF data about the resource, or its web page representation if available).

Check it by yourself: URI referring to Frederick Giasson

The result is that readers have directly access to my profile, articles I wrote, etc.

3. Actionable URL

Sometimes it can be really interesting to be able to act according to some URLs. One example is when a web page, or a resource (identified by a URI) refers to a thing that can be bought. By example: something that can be bought on Amazon.com:

Check it by yourself: Visualizing the Semantic Web

From the blog post, the reader can automatically buy the related resource on Amazon. This is only one possible action, but many others are possible; the only limit is imagination.

Conclusion

The simple links you create from your blog posts to other web pages have much more related information than you can think. Using this prototype Zitgist WordPress plug-in will explicit these links for your reader.

You only have to read some of my other blog posts to try it by yourself. Some results are quite impressing.

I will make this plug-in available for download sometime next week.

This idea has been promoted by Kingsley Idehen for some time now. He uses to call this idea enhanced anchors, or, a++. The idea is simple: enhancing anchors to explicit links to a certain resource (URI or URL), and optionally to perform some action on them.

This prototype is a first try in that direction. Many upgrades should follow so we really unveil the power of this new kind of linking; of this new way to relate things together, and to explicit these relations. Please report me any bug, issues, cross-browsers problems, comments, suggestions, etc.

It is not because we had some issues with the Zitgist Browser‘s server that things stopped at Zitgist. In fact, many projects evolved at the same time and I outline some of these evolutions bellow.

New version of the Zitgist Browser

A new version of the browser is already on the way. In fact, the pre-release version of the browser was a use case; a prototype. Now that we know that it works and that we faced most of the issues that have to be taken into account to develop such a service, we hired Christopher Stewart to work on the next version of the browser. He is already well into the problem now, so you could expect a release of this new version sooner than you could be expecting. At first, there won’t be many modifications at the user interface level, however, many things will be introduced in this new version that will help us to push the service at another level in the future.

New version of Ping the Semantic Web

The version 3.0 of the PingtheSemanticWeb.com web service should be put online next week. It will be a totally new version of the service. It won’t use MySQL anymore; Virtuoso has replaced it. The service will now fully validate RDF files before including them in the index. More stats will be available too. It is much faster (as long as remote servers are fast too) and I estimate that this only server could handle between 5 to 10 million pings per day (enough for the next year’s expansion). This said, the service will be pushed at another level and be ready for more serious traffic. After its release, a daily dump of all links will be produced as well.

The first draft of the Bibliographic Ontology

The Bibliographic Ontology Specification Group is on fire. We are now 55 members and generated 264 posts in July only. Many things are going on here and the ontology is well underway. We should expect to release a first draft of the ontology sometime in August. If you are interested in bibliographic things, I think it’s a good place to be.

The Zitgist Semantic Web Query Service

Finally, Zitgist’s Semantic Web Query Service should be available for alpha subscribed users sometime in September. You can register to get your account here. Also, take a look at what I wrote about vis-à-vis this search module (many things evolved since, but it’s a good introduction to the service).

Conclusion

So, many things are going on at Zitgist and many exiting things should happen this autumn, so stay tuned!

Five weeks ago I introduced the Zitgist Browser on this blog. At that time, I talked about a pre-release of the service. These two little words probably helped to explain what followed in the following weeks.

In fact, some of you probably noticed that the Zitgist Browser was down half of the time for a couple of weeks. In fact, we found many issues at many levels that rendered the browser's server unstable. In the last weeks, we performed a battery of tests to fix all issues that appeared. Now, about three weeks later, the server is back stable. At least, it has been online for the last couple of days without any issues.

Thanks to the OpenLink Software Inc. development team, we have been able to stabilize the service; and it wouldn't have been possible without their help and expertise.

Finally, stay tuned for the next release of this service and continue to use it and report issues that you could encounter while browsing the semantic web (more information about the next version in the next blog post); and sorry about the possible frustrations you possibly had when you used the unstable version of the service.