reification and procedures [was: RE: RDF Terminologicus]

[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. 


: >[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>

Received on Friday, 5 January 2001 04:37:32 UTC