Identity and extensibility

Okay, this is a hairy topic. I wrote something about it, ran into problems, discarded it, ran in circles for a weekend, and still haven't figured it out. Well, what the hell, I'll just write something about it anyway. :-)

What does extensibility mean in the context of RDF? What readily comes to mind is that if I have a FOAF description of a person, and I want to express something more about that person, then I can just create my own property -- foo:annualSalary, say -- and add it to the FOAF file. That's part of the story.

In my previous post, I made the distinction between real-world resources, mathematical objects, and virtual resources. The difference between these is how they come into existence:

• Real-world resources exist already before we talk about them in RDF. We just refer to them, and expect that there is general agreement about what they are. (That's a working illusion, of course: "What is art?") To know whether there is a real-world resource about which particular statements are true, you need to look in the real world. Same for knowing whether two real-world resources are the same.
  
• Virtual resources exist because someone created them in a computer. If a user has created a folder, the system knows that this folder exists. If a user has created a website, a computer can load it through HTTP and thus know that it exists. Knowing whether two virtual resources are the same can (often? always?) be decided inside the computer.
  
• Mathematical objects exist because someone defined what they are. In a sense, a class of mathematical objects (such as the natural numbers) is a virtual resource, because it exists because a user made it exist. Whether two mathematical objects are the same solely depends on their definition.

Now, half of extensibility is being able to add new properties about existing resources; the other half of extensibility is the ability to define new resources. Hmm, it's hard to phrase this generally; let me give you an example. Let's say that you want to write an implementation of a LISP dialect in Fencore, and you represent LISP lists as RDF lists, like this:

    _:a rdf:first "First element".
    _:a rdf:next _:b.
    _:b rdf:first "Second element".
    _:b rdf:next rdf:nil.

Now, some of these lists represent LISP programs that come from some source file, and when something goes wrong during execution, you want to be able to tell the user which source file the code came from in which a bug occurred. Did the list (pr x) come from foo.lisp or from bar.lisp?

    _:a rdf:first lisp:pr.
    _:a lisp:source <foo.lisp>.
    _:a rdf:next _:b.
    _:b rdf:first var:x.
    _:b rdf:next rdf:nil.

    _:x rdf:first lisp:pr.
    _:x lisp:source <bar.lisp>.
    _:x rdf:next _:y.
    _:y rdf:first var:x.
    _:y rdf:next rdf:nil.

But what if RDF lists are defined so that any two lists with the same rdf:first and the same rdf:next are considered to be the same list? Then _:a and _:x are the same list! And therefore, it is true that both

    _:a lisp:source <foo.lisp>.
    _:a lisp:source <bar.lisp>.

(In fact, the RDF and OWL specifications are silent on whether two lists are the same if they have the same rdf:first and rdf:next, I think.)

So an extensible definition of lists would say that for every resource _:f and list _:r, there is at least one list _:l such that _:l rdf:first _:f and _:l rdf:rest _:r, but it wouldn't say that there is only one such list. In fact, it would say that more than one such list may be defined to exist.

We would then usually be talking about "every list with this rdf:first and this rdf:rest," rather about "the one" such list.

But I find it difficult to come up with compelling use cases where this would be very important, so maybe this particular sort of extensibility isn't as important as I thought. I'm not sure yet.