Semergence

Identity, Reference, and the Web (IRW2006) Workshop

> Our immediate goal for this workshop is to explore the nature of identification and reference on the Web, > building on current work in Web architecture, the Semantic Web, and informal community-based tagging > (folksonomy), as well as current practice in XML and theory in philosophy and linguistics.

I’ve been reading the PDFs and papers that will presented at this workshop, and I’m really gaining a greater understanding for the whole httpRange-14 problem. I’ve always known it’s a problem, but I’ve brushed it off hoping that it won’t affect me in Real Life.

However, as RDF is moving more and more into knowledge management arena (and I’m not sure it should go there anyway), the issues of identity are extremely important.

At this moment, I’m subscribing to the “It’s on the web if it has a URI. Who cares if I can’t actually retrieve a representation from the URI?” URI identify Resources, which as we all know are things that can be identified by a URI. A bit cyclic, to be sure. However, it’s broad enough (for me) to mean that anything can be given a URI. Things might be identified with multiple URIs, even.

Now, the larger issue of “How can we know anything about what a URI identifies?” comes into play. This is the reader vs writer issue, as we attempt to reconcile if the author of the URI is the one that can dictate what the URI identifies or if the consumer is able to assign meaning.

I believe that meaning is relative, and that the reader, with their unique experiences and perspectives, will always interpret things in their own way. The readers, or consumers, will always have more power with regards to information interpretation.

This is why I think it’s OK if <http://example.org/x14> identifies a Beach, a Park, a Seashore, and a Playground all at the same time. As long as when two people are communicating about <http://example.org/x14> they are able to agree that they agree that it identifies the same conceptual entity, it should be a short leap to also agree that a beach can be a park can be a seashore can be a playground.

Of course, the granularity of what one party may consider <http://example.org/x14> can be very different than another party. It’s at this point that if Party A wants to be _more specific_ in what it considers is identified by <http://example.org/x14>, it will need to either be OK with Party B’s more general interpretation, or will need to commence some sort of negotiation in order to agree.

For example, take this conversation:

A: “Where are you?”
B: “At kailua beach”

At this point, A should know what Kailua Beach is _in very general terms_. If A just was simply curious at a high level, this conversation is over. However, A might want to meet up with B, so A asks:

A: “Where at the beach are you?”
B: “Oh, to the left of the showers, next to the tree”

Now A should have a very good idea of where, in more exact terms, B is located.

In this example, B’s location is <http://example.org/x14> which can be interpreted many different ways (eg, “at the beach”, “at some lat and long”, “next to a tree”). The consumer of the information must make the determination if they have enough information to make a sound decision. This requires perspective (what other statements in my RDF graph do I have about the URI?) and can’t be provided or assumed by the publisher of the URI.

Hm, so what did I say in this post?

I believe URIs can identify things whether or not they have representations on the web.

I believe that they things URIs identify can be interpreted in many different ways. Using some owl:disjointWith can help to notice when two or more parties are in arguments.

I believe that interpretation is a local operation, performed by the reader or consumer of information.

It’s very possible that conversations between semantic web agents will be required to come to a sort of shared understanding.

Henry has discovered SWOOP, a small ontology editor from MindSwap. This reminds me to point out a very nice feature of SWOOP, one that Protege does not have out of the box.

SWOOP, through its integration with Pellet, is able to not only compute classifications but also able to tell you *why* your ontology is inconsistent. This, to me, is a huge step towards being able to use ontologies in “every day” problems.

The use case here is: You are collecting information from many many different sources. You have an ontology that defines your view of the world. It’s possible that all the different information sources will present to you conflicting information. Your ontology defines what is consistent, so therefore it should be able to tell you when you have information that is *inconsistent*.

SWOOP does a pretty good job at giving you the feedback to find the source of the inconsistency. An example output is:

Inconsistent ontology Reason: Individual ErrorBoat has more than 1 values for property at
Location
violating the cardinality restriction
Axioms causing the problem:
1) (ErrorBoat decommissionedAt DryDock)
2) |_(DryDock ≠ SanDiego)
3) |_(ErrorBoat deployedTo SanDiego)
4) |_(ErrorBoat rdf:type Boat)
5) |_(Boat ⊆ (= 1 atLocation))

Now that’s a simple problem, where an instance has two values for a property that is constrained to have only one.

What about when an individual belongs to two disjoint classes? This one is a bit more confusing if you don’t have a background in DL, but if you stare long enough at it, you might see the real cause:

Inconsistent ontology Reason: Individual ErrorBoat is forced to belong to class
all(decommissionedAt, not(Location))
and its complement

Axioms causing the problem:
1) (ErrorBoat decommissionedAt DryDock)
2) |_(DryDock rdf:type Location)
3) |_(SanDiego rdf:type Location)
4) |_(ErrorBoat deployedTo SanDiego)
5) (Decommissioned ≡ (∃decommissionedAt . Location))
6) (Active ⊆ ¬ Decommissioned)
7) (Active ≡ (∃deployedTo . Location))

To explain this one better, I’ve declared that the class Active and the class Decommissioned are disjoint. And I’ve placed the instance ErrorBoat into both classes.

For this reason, I like SWOOP and Pellet. Though, Protege still has nicer workflows.

Phil asked for clarification on a previous post, so hopefully with some sleep in me I can elaborate a bit more. I think I was trying to say that the concept of weight can be modeled in many different ways. This includes different ontological descriptions for weight, where weight can be identified using the same or different URI.

Take, for example, the URI http://example.org/xyz. You can say that:

<http ://example.org/xyz> a :Animal.

and I can say

<http ://example.org/xyz> a :Car.

The context here is Who Said What. What’s not up for question is that there is some Resource identified by <http ://example.org/xyz>, and that when we use that identifier, we are talking about the same thing.

For the semantic web to succeed, and this might be your point all along, the environment must be able to cope with the above situation (where you think the thing is an animal, and I think it’s a car) . This is difficult because of the Open World assumption, no doubt about it. For all the reasoner knows, something can be a :Animal and a :Car. It’s up to the authors of the ontologies to say that :Animal owl:disjoint :Car.

Even though the Open World assumption exists, URI’s still identify one thing. Now, whatever meaning you assign to that thing is your own. It’s the meaning that is context relative, not the identifier for the thing.

SSSW OWL Examples contains OWL reasoning examples, including OWL ontologies and explanations as to what inferences can be made. This is a good source of OWL statements and what they can mean to a reasoner.

OWL Rules in JESS includes Jess rulebase based on OWL Semantics. This implements a lot (how much?) of OWL inside JESS.

JTP: An Object Oriented Modular Reasoning System

> JTP is an object-oriented modular reasoning system developed by Gleb Frank in Knowledge Systems Laboratory of Computer Science Department in Stanford University. JTP is based on a very simple and general reasoning architecture. The modular character of the architecture makes it easy to extend the system by adding new reasoning modules (reasoners), or by customizing or rearranging existing ones.

> The system is implemented in Java. The reason for this choice is that Java is ideally suited for easy integration of object-oriented systems, which facilitates both extending JTP’s functionality and embedding JTP in other systems. The abundance of supplementary software available in Java also helps.

EulerMoz is an inference engine written in Javascript. Based on the original Euler proof mechanism.

> EulerMoz is an inference engine supporting logic based proofs based on EulerSharp project.

Ontology Driven Architectures and Potential Uses of the Semantic Web in Systems and Software Engineering

Wow, I was just asking about software engineering concerns specific to the semantic web, and here we go.

> This note outlines the benefits of applying knowledge representation languages common to the Semantic Web, such as RDF and OWL, in Systems and Software Engineering practices.

Danny nicely puts the problem I’m trying to solve in his post titled SPARQL trick #23. He says:

> Running inference on the store’s data as a whole may be expensive, but without it many results for a given query may be missed.

This is exactly why we are attracted to semantic web technologies. I have a lot of data, but I know there are many more pieces of information in there if I can apply some ontologies and rules. My queries against the system must search both the raw triples I have plus any triples that can be inferred by my ontologies. To me, this is one of the main value adds of the system.

The other main value add of a RDF store vs. a traditional relational store is that it’s much easier and cheaper to say arbitrary things. In a relational store, your schema must be defined up front, severly limiting your ability to define data in the future. With RDF, saying anything about anything is cheap.

There are some solutions that work well for data sets that are static. You simply write your ontologies and rules, then run your triplestore through the reasoning engine. Bingo, you’ve got 4-5x more triples. Search away!

Problem with that is, users expect live, real time interaction with the system. They want to add a new triple, and then have immediate access to any newly inferred triples. Therefore, the batch run of your rules won’t work in this scenario.

It might work to apply the rules and ontologies at query time. Treat them like regular business logic that you would write in your object model. This logic is run when requested, not run in batch with results written to the database (in typical web applications, that is). How performant would it be to treat ontologies and rules like business logic, and thus treat the triple store as a traditional relational database (that is, dumb and full of data)?

Looks like I’ll give this a shot, and see where it leads us. Much like the ActiveOntology work being done over in Ruby, wiring in Jess or Drools as a base class for a Java object model might make sense here.

Of course, the downside of this is that it will never be as performant as the reasoning engine living inside the database. Time to integrate Jess directly with PostgreSQL?

OWL Inference Engine in Jess

> This page contains source code and instructions to load OWL ontologies and annotations into a JESS knowledge base