Re: Proposed agenda

In case it might help, I summarized what we came up with as list of  
features that various people associate with the term "information" as  
an outcome of a recent workshop we had on a beginning a new ontology  
effort within the OBO.

http://neurocommons.org/page/Features_associated_with_information

The proposal at the bottom is Barry's - I think it needs work. Some  
initial comments at
http://groups.google.com/group/information-ontology/msg/62abf0fa8cf17288

There's a but more discussion in a mailing list I've set up - I still  
need to forward some previous emails to fill in the earlier discussion:

http://groups.google.com/group/information-ontology

-Alan

On Jun 23, 2008, at 5:34 PM, Booth, David (HP Software - Boston) wrote:

>
>> From: Jonathan Rees [mailto:jar@creativecommons.org]
>> . . . .
>> I don't get this. What makes IRs special? Is it that maybe we
>> aren't talking about a class? But I hear statements from all
>> group members of the form "x is not an IR" and while they may
>> be mysterious or controversial, they don't seem ill-formed or
>> semantically problematic.
>
> No, it's fine to think of IRs as being a class. More explanation
> below . . .
>
>>> . . .  No amount of
>>> discussion of whether an IR has mass, has a dc:title, has a
>>> number of pages, has a license, has spelling errors, etc.,
>>> will help.
>>
>>
>> I don't understand this either. If you're saying it's not an
>> ontology problem, like that of coming up with the most fruitful
>> way of talking about chemical reactions or credit card
>> accounts, then what sort of problem is this?
>
> There are two problems. One indeed is an ontology
> problem: how to define "information resource" in a way that is most
> useful to web architecture. I do think it would be helpful for
> the TAG to adopt a better definion than the one that is currently
> in the AWWW document.
>
> But aside from the ontology problem there is the problem of what
> that definition means to semantic web architecture -- how it is
> used -- and this is the issue of identity and reference.
>
> It is natural to want to separate these two problems
> and focus first on the (simpler?) ontology problem,
> but I don't think it works to do that, because without first
> having a clearer idea of what that definition will mean in the
> architecture, attempts to better define "information resource"
> lead straght into a tar pit.
>
> For example, instead of asking:
>
>        "Can an IR have mass?"
>
> the question would be better stated as:
>
>        "In semantic web architecture, can a resource be both an IR
>        and also have mass?"
>
> (Answer: Sure.) The question has been rephrased in two important
> ways:
>
> - The context is semantic web architecture, because that's the context
> in which we need to ask such questions.
>
> - The question acknowledges that in semantic web architecture, a
> resource can be viewed in more than one way: its characteristics
> can simultaneously match more than one thing. So depending on the
> ontological definition of IR, a particular resource might very
> well be considered both an IR and something that has mass.
>
> The point is that a clearer understanding of identity and
> reference in semantic web architecture dramatically changes the
> ontological debate: suddenly we don't need to worry as much about
> whether some hypothetical thing *is* an IR. Instead we can focus
> the ontological discussion on the characteristics of an IR that
> matter to semantic web architecture, while recognizing that a
> resource can have IR characteristics in addition to having other
> characteristics.
>
>>>
>>>> So I propose to take up your question: What are the
>>>> characteristics of an IR? Or more broadly, what *might* be,
>>>> what *has to be*, what
>>>> *cannot be* the characteristics of an IR?
>>>
>>>
>>> If you believe what I've been saying about how resource
>>> identity works in semantic web architecture, then the answer
>>> is simple. Assuming C is the set of core assertions for the
>>> definition of IR:
>>>
>>> Q: What *might* be an IR?
>>> A: Anything whose core assertions are logically consistent with C.
>>>
>>> Q: What *has to be* an IR?
>>> A: Anything whose core assertions subsume C.
>>>
>>> Q: What *cannot be* an IR?
>>> A: Anything whose core assertions are logically inconsistent with C.
>>
>>
>> OK. (Although this seems to contradict your assertion that in
>> order to define IR we need to get into questions of identity
>> and reference.) Tell me what you think C is and we'll have
>> something to talk about.
>
> The point of the Q&A above is to illustrate the fact that,
> regardless of which definition of IR is chosen, a clearer notion
> of identity and reference makes these questions much simpler to
> answer.
>
>> Well... you have said one characteristic of an IR (an assertion
>> in C) is that an IR is a function, and I have balked at the
>> idea that functions have authors.
>
> That's a perfect example of what I mean. It isn't a question of
> whether a *function* can have an author. It's a question of
> whether a *resource* can be both a function and something that
> has an author, i.e., whether the core assertions of that resource
> subsume the core assertions for "function" and the core
> assertions for "thing that has an author".
>
>> If you're trying to play some trick, or apply a modification to
>> the normative RDF semantics,
>
> No trick, and AFAIK I'm not trying to change the normative RDF
> semantics.
>
>> . . .
>> We're just trying to come up with some rules to guide decisions
>> about what's OK to say (and infer) in RDF. We seem to agree
>> that we don't want to be allowed to say that an IR has mass, .
>> . . .
>
> Again, I think that's the wrong question. It isn't a question of
> whether an *IR* has mass -- an IR does not intrisically have mass
> -- but whether a *resource* can be both an IR *and* something
> that has mass, and the answer to that is very much the issue of
> resource identity and reference.
>
>
>
> David Booth, Ph.D.
> HP Software
> +1 617 629 8881 office  |  dbooth@hp.com
> http://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.
>

Received on Tuesday, 24 June 2008 06:47:35 UTC