Re: reification and procedures [was: RE: RDF Terminologicus]

At 09:36 AM 1/5/01 +0000, Bill dehOra wrote:


>[I've moved this into a different thread, it's off-topic for
>terminology]
>
>: [Graham] I see nothing gained by allowing
>: aggregation of reifications in the way you
>: suggest, and possible loss of expressive
>: options.  (Eventually, I dare say
>: we won't use all these possible options,
>: but until we better understand how
>: to deal with a range of info modelling
>: issues I'd prefer to keep open as
>: many options as possible.)
>
>I'm not proposing that aggregation should be a normative aspect of
>RDF. But I am certain that if RDF reification is to be used in an
>open distributed system, reifications will be aggregated in no small
>way by implementations. So it doesn't hurt to think about it now,
>even if one is modeling data only.

Fine.

In which case, I suggest that merging of reified statements should follow 
the same patterns (whatever they may be) as merging of any other 
resources.  Certainly there would be situations in which two 
differently-identified reification resources can be regarded as equivalent.

As for the rest, I won't respond point by point because I don't really 
disagree with the essence of what you say.  The distinction I'd draw is 
that I'd like to define _meaning_ without reference to procedure, even 
though I acknowledge that the discovery of that meaning must ultimately 
depend upon a some procedure.  (I think there's a parallel here with the 
SWeb/DAML work on providing a common proof validity checker that doesn't 
care how the proof may be discovered.)

So, one may wish to compute the effect of retracting a statement from a 
statement set, and need an efficient procedure for doing this in terms of:

    new_meaning := some_function( previous_meaning, statement_set, 
retracted_stmt )

But I think that the meaning of some set of statements should not be 
dependent on some prior dynamic computational state; e.g.

    meaning = some_function( statement_set )

or

    meaning = some_function( statement_set, context )

(where 'context' is a static, invariant environment to which the statements 
are bound for the purposes of evaluation).

#g
--

>: >[Bill]
>: >We have to remember that statements live
>: >on their own outside the
>: >reification. This example shows why I whine
>: >about procedural semantics for
>: >statements involved in a reification.
>: >I'm stealing it :)
>:
>: [Graham]
>: I'm not sure I understand what
>: you're trying to say [...]
>
>I'm saying (not very clearly), that reification needs to be
>considered with procedure in mind.
>
>
>: [Graham](a) I don't recognise retract as
>: a legitimate option, other than as an
>: implementation technique when constructing
>: models.  Once a statement has been stated,
>: it exists;  it may be forgotten, or
>: ignored, or refuted, but not abolished.
>
>Well, in a way all statements already exist, waiting to be
>discovered, if you buy into a platonic view of mathematics. I can't
>actually make a statement vanish as far as I can tell, but I can make
>a reference to one vanish from a computer. I expect that retract semantics
>will be used in many cases rather than adding new statements that
>override previous ones, since it's computationally more efficient to do so.
>Implementation and manipulation of statements which are first class entities
>
>as well as being an integral part of a reification that isn't a first class
>entity is what concerns me. They require different treatment, or will, when
>RDF is used in anger. I'd hope to see a statement on this when the wg
>for a future M&S is formed, even if it's only an explicit punt to
>implementation dependent.
>
>
>: [Graham] (b) I am not trying to invoke procedural
>: semantics.
>
>I am.
>
>
>: If anything, I'm a wannabe functional
>: programmer, ever since I read John Backus' ACM
>: Turing award lecture, oh so many years ago.  I
>: really like the cleanliness and relative
>: predictability of non-procedural definitions.
>
>Even so, functionally denotated descriptions are generated for the
>purposes of computation. Non-procedural definitions for computers
>are largely a myth, snuggling cosily with the "look ma, no programming"
>myths of declarative syntaxes. Plus we are after all supposed to building
>a more machine process able web.
>
>-Bill
>
>-----
>Bill de hÓra  :  InterX  :  bdehora@interx.com
>
>
><mildrant>
>The premise that we can just declare non-procedural assertions in a
>formal way without regard to computation and then let some
>programmers loose to reckon with them is highly questionable, it
>assumes in my mind that inference is to be deductive (it must, or how
>would we know when to stop declaring stuff?) and thus all process
>models to operate over RDF are in some sense deductive logic programs
>or theorem provers. Another Turing award winner, Marvin Minsky,
>has been saying as much for years. I recommend that anyone who
>is modeling in RDF read Drew McDermott's "A Critique of Pure Reason".
>RDF doesn't quite fall into this denotation only tar pit, since it has
>an associative aspect derived from semantic networks and
>graphical models (so it has a semblance of process and organises
>things in part for the benefit of a computer), but the semantic web
>isn't going to work out without scrutiny of how RDF statements will
>be computed. The only reason we would ever want to assert a statement
>at all is to act upon it. If there are others, I'd like to know.
></mildrant>

------------
Graham Klyne
(GK@ACM.ORG)

Received on Friday, 5 January 2001 08:04:21 UTC