Universal semantics namespace

From Pelennor

The biggest problem with Semantic Web, in practical usage, is how to develop and maintain ontologies and also the rules / logic to go with them.

We sometimes forget the real use of data - that of providing value to humanity in various forms, and providing true functionality as the humans need it. Connections are good, but functionality is paramount. The fact that a company can store ticket information on the web is not sufficient, but the user being able to buy it is significant. A company storing data is not sufficient, it being able to sieve out information from it, transforming it into knowledge, and converting to action is paramount. Somewhere along this, functionality becomes the significant aspect.[ http://web3next.blogspot.com/2007/11/ggg-www-123.html ]

Let us use the ticket as our example here. The current way of doing things is for each entity that sells tickets to design their own schema for data and logic of their "ticket selling application." Regardless of the development methodology or tooling chosen, the result is essentially the same: custom database schema, custom data objects, custom business objects, custom view objects, custom controller code.

With the universal semantics namespace, we can re-use existing semantics for our application by pulling in definitions from the web or P2P global graph. The key is that many semantics can apply to the same piece of data and those semantics will be very fine grained and generic to maximize re-use. For our ticket application, we might use the following namespaces (in parenthesis, what each is used for):

• com.example.product.ticket (basic info relevant to any type of ticket)
• com.example.event.concert (info related to a concert event)
• com.anotherexample.object.person.id (personally identifiable info on person who will own the ticket)
• com.anotherexample.object.business.relationships.customer (information related to entity being a customer relationship)
• com.yetanotherexample.object.business.transactions.sale.product (information related to sale of a product)

Note that just because we use a particular domain in a namespace doesn't mean we have to fetch anything from a centralized location. Using the P2P model, we can send out a request for any entity and only resort to the original URI if necessary. (something like a P2P distributed DNS)

This is very similar to existing W3C Semantic Web, minus the P2P part, but here's where it gets more interesting: Instances of certain pieces of semantically rich information can be shared. This is where database concepts enter the picture. Suppose you are the ticket buyer. You will have a personal instance of data conforming to a subset of the com.anotherexample.object.person.id namespace (or a namespace that is mappable to it) If the ticket seller does not want to store this information, they can simply hold on to the UUID of your instance. In this case, due to trust issues, it is rather likely they would store the original information, but among friends, this would be unnecessary. In fact, since certain data entities change frequently (or take up too much storage space), a caching model is more likely.

The obvious question is: How do we prevent there from being hundreds of alternative namespaces for each of those examples? Essentially, we cannot, but de-facto standards will evolve over time and it is likely that standards bodies will rise up for certain domains of information. However, we don't need design-by-committee, only refactoring of what others have produced and have become popular. One of the primary concepts is that if a schema is fine grained enough, there should not be collisions. To illustrate, the example of *.business.relationships.customer namespace should describe no personally identifiable information because it does not necessarily apply to a person. The only type of information in that namespace should be concepts in its tiny domain. (customer relationship established/terminate dates, type of relationship, etc.)

(to be continued..)