FYI, Jonathan Rees and I had lunch on Friday and talked for a few hours about semantic web architecture, how resource identity and reference work, and how information resource (IR) should be defined. We did not necessarily agree on everyting, but we did seem to gain better understanding of what each other was trying to say. We talked mostly about technical issues, but also talked briefly about the procedural issue of how to make progress.
PROCEDURAL:
- I did not seem to get much traction on the call last week in trying to explain why it is important to have a clearer notion of resource identity and reference before nailing down a definition of IR, so I don't think it would be fair to the group to try to push this further right now. So it's fine with me if the group focuses for the moment on the ontological question of what should be the definition of IR.
TECHNICAL:
A few technical points I tried to make:
- There is no *architectural* need for IR to be disjoint from Person. Having a resource that has characteristics of an IR and characteristics of a Person is architecturally no different than a resource that is unambiguous enough for some applications but ambiguous for others, such as AKT versus AKT1, AKT2, AKT3 in
http://dbooth.org/2007/splitting/#akt
and this issue of a resource being unambiguous enough for some applications but too ambiguous for other applications is inevitable, as Pat Hayes has pointed out on several occasions.
- There is no difference in principle between defining IR to be disjoint from JournalArticle and defining IR to be disjoint from Person. These are merely two different arbitrary points on a spectrum from from a less constrained to a more constrained definition of IR.
- A definition of IR that is less constrained is more reusable, but a definition that is more constrained can catch more errors, and vice versa.
- In discussing whether the definition of IR should say that "an X is not an IR", where X might be the class of JournalArticles, for example, we should be clear whether we mean:
a1. an X *cannot* be an IR; or
b1. an X is not *necessarily* an IR.
In other words, we should be clear whether we mean:
a2. For any resource r, { r rdf:type X } implies NOT { r rdf:type IR } ; or
b2. For any resource r, NOT { { r rdf:type X } implies { r rdf:type IR } } .
or, restating b2:
b3: There exists a resource r such that { r rdf:type X } and NOT { r rdf:type IR }.
I don't think this has always been clear in discussions of IR.
Finally one more technical point that I did not make during our discussion, but would like to point out now, if we are going to focus on the ontological question of the definition of IR:
- Following the basic architectural "principle of least constraint"[1], the TAG's definition of IR should constrain an IR *only* to the extent required by the architecture. (The definition of IR is relevant to the architecture because the architecture has more things to say about resources that are IRs than it does about other resources: they can have representations, rules of content negotiation and media types come into play, etc.) However, it would be fine to define additional, more constrained subclasses of IR for convenience, once there is a least constraint base definition.
Reference
1. http://users.ece.utexas.edu/~perry/work/papers/swa-sen.pdf
David Booth, Ph.D.
HP Software
+1 617 629 8881 office | dbooth@hp.comhttp://www.hp.com/go/software
Statements made herein represent the views of the author and do not necessarily represent the official views of HP unless explicitly so stated.