Identity, Reference, and the Web (IRW2006) Workshop

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 <> identifies a Beach, a Park, a Seashore, and a Playground all at the same time. As long as when two people are communicating about <> 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 <> 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 <>, 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 <> 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.

Popular posts from this blog

  • Sponsor:  Register today for  New Game, the conference for HTML5 game developers . Learn from Mozilla, Opera, Google, Spil, Bocoup, Mandreel, Subsonic, Gamesalad, EA, Zynga, and others at this intimate and technically rich conference. Join us for two days of content from developers building HTML5 games today. Nov 1-2, 2011 in San Francisco.  Register now ! This is the second article in a Box2D series, following the Box2D Orientation article. The Box2DWeb port of Box2D contains a nice example to show off the basics of integrating physics simulations into your web app. This post will provide a walkthrough of the example, explaining the high level concepts and code. First, let's see the example in action. The code for the above is open source and available on GitHub. It was adapted from Box2DWeb's example . Animating Before we look at Box2D, it's important to understand how the above simulation is animated. You might think setInterval or setTimeout is
  • In which I port a snazzy little JavaScript audio web app to Dart , discover a bug, and high-five type annotations. Here's what I learned. [As it says in the header of this blog, I'm a seasoned Dart developer. However, I certainly don't write Dart every day (I wish!). Don't interpret this post as "Hi, I'm new to Dart". Instead, interpret this post as "I'm applying what I've been documenting."] This post analyzes two versions of the same app, both the original (JavaScript) version and the Dart version. The original version is a proxy for any small JavaScript app, there's nothing particularly special about the original version, which is why it made for a good example. This post discusses the differences between the two implementations: file organization, dependencies and modules, shims, classes, type annotations, event handling, calling multiple methods, asynchronous programming, animation, and interop with JavaScript libraries. F
  • Angular and Polymer, sitting in a DOM tree, B-i-n-d-i-n-g. First comes components, Then comes elements, Then comes the interop with the node dot bind. Angular , a super heroic MVC framework, and Polymer , polyfills and enhancements for custom elements built on top of Web Components, can live harmoniously in the same app. This post shows you how to connect Angular-controlled components to Polymer-controlled elements via data binding. And we do it all in Dart . Angular and Polymer I get asked "Should I use Angular or Polymer?" a lot. My answer is, "Yes". That is, both libraries have distinct strengths, and you can use both in the same app. Polymer excels at creating encapsulated custom elements. You can use those custom elements in any web app or web page, regardless if that app is built with Angular, Ember, etc. Angular excels at application engineering, with dependency injection, end-to-end testability, routing, and services. Here are som