Re: Requirements for Any Theory of "Information Resource"

On Fri, Mar 4, 2011 at 1:53 PM, David Booth <david@dbooth.org> wrote:

>> This would be just one particular interpretation. It is not a
>> requirement and I see no reason to try to foist that particular model
>> on everyone.
>>
>> (I have said this to you dozens of times over the years and just don't
>> understand why we're not communicating.)
>
> Uh . . . I don't know what pushed your button on that one, since this
> was the first time I had even seen the 'has reading' relation, but:
>
> 1.  The sentence in your draft said "'Has reading' is not functional,
> *because* . . . ." (my emphasis).  The word "because" suggests that 'has
> reading' *must* not be functional, for the reason given.  I was pointing
> out that the fact that readings could indeed "vary by media type,
> language, session, time, whim, etc.", but "has reading" could *still* be
> functional.  If you don't want it to be functional for other reasons,
> then fine, but it is wrong to imply that it is functional *because*
> "readings vary by media type, language, session, time, whim, etc.".

I will clarify this. This is just an invocation of Occam's razor. By
"is not functional" I meant "is not required to be functional" - and
in the applications I have in mind cannot be functional, because of
the need to model conneg etc.

> 2. Regarding your comment about my attempt to "foist" a functional model

There is a very important distinction between "function" and
"functional". Functions are very nice in mathematics. "Functional" has
a technical meaning in logic; it is a metaproperty of relations. For
example 'has mother' is functional not because it's part of
mathematics but because anything that has a mother has only one.
(well, at least until recently.) For explanation of the word see any
OWL tutorial.

> on everyone, you have introduced a *relation* 'has reading'.  A function
> is a special kind of relation.  Generally when one is attempting to
> model or explain something, it is best to choose the *most* specific
> designator that is applicable -- "function" being more specific than
> "relation".

Relations ("properties") are just two-place predicates. You can't
write a sentence with a transitive verb or any interesting first-order
logic without using a relation.

Specific designators mean unnecessary constraints on models. Occam's
razor says avoid such constraints, as does the engineering method of
requirements preparation. If you list something as a requirement
that's not required, you are saying something untrue.

So this is not an attempt to explain anything. It is an attempt to say
what properties any explanation would have to have, in order to enable
a particular metadata practice. The informative text talks about
possible models, but that's just to help you to build your own.

> Furthermore, being functional corresponds closely Roy's
> REST model, RFC 2616 and the way a web server works: it receives a
> request at a particular time and returns a result that depends only on
> the request and (conceptually) the time.  (The time parameter is a
> catch-all to account for any other outside stimulus, such as current
> weather conditions.)

I could explain again how and why I think Roy is wrong, but I would
just be repeating myself.

> So let me turn this around: if 'has reading' *can* be defined to be
> functional, why *not* do so?  If it would add more complexity than would
> be worthwhile, then fine, let's not do it.  But I *do* think there is
> value in doing it if it doesn't add too much complexity, because it
> would correspond more closely to the real world.

Occam's razor.  And you yourself have said the real world doesn't
always matter - e.g. an information resource can be a toucan. I don't
agree, but it's sort of confusing.

Listen, all I'm doing is using a standard term 'functional' and saying
I won't be writing an axiom 'has reading is functional' because there
are situations that I want to fall under these axioms where it is not,
i.e. there are x, y, z with y != z such that x has reading y and x has
reading z. In particular, y and z could be conneg variants, or
different versions over time. This has nothing to do with whether
anything is a function, and I don't (yet) see a reason for the axioms
to be very specific about this - it's just not necessary to take *any*
stand on it.

> Yes, you have given a better definition.  That doesn't mean we need to
> mint a new term.  The existing definition of log:uri is pretty much
> vacuous semantically, so it could be used in conjunctions with the
> criteria that you have set out.

But if it doesn't mean what it has to mean for this application, it
would not be correct to use it. And the only guide I have to what it
means is the RDF file.

Maybe I could get Tim to change his documentation - but then that
might break clients of that ontology.

>  I think it is helpful to use terms that
> are already in use if possible.

Definitely. But not if doing so creates incorrect or incomplete inferences.

Anyhow a mapping of the axioms to RDF would be just one interpretation.

> OTOH, if you really want to mint a new term then I think we should at
> least indicate (in a comment) its relationship to log:uri.

Will try to remember this (I probably will since I try to always
compare any terms I invent to existing ones)

Jonathan

Received on Friday, 4 March 2011 22:09:34 UTC