W3C home > Mailing lists > Public > www-rdf-logic@w3.org > April 2001

Re: Reification

From: David Allsopp <dallsopp@signal.dera.gov.uk>
Date: Tue, 10 Apr 2001 16:11:32 +0100
Message-ID: <3AD322A4.96EFA505@signal.dera.gov.uk>
To: Danny Ayers <danny@panlanka.net>
CC: www-rdf-logic@w3.org

Danny Ayers wrote:
> <- IANAL*, but I think it's because an arbitrary machine C, which only
> <- knows 'standard' RDF, won't understand, and will not be able to process
> <- the data in the way intended by A. The data then have different meanings
> <- to different machines, which defeats the whole purpose of the semantic
> <- web. The negation is not built-in to RDF, so it has no meaning in its
> <- own right. The meaning is 'outside' the system, as in Pat Hayes'
> <- "punched cards with writing on them".
> Any processing is going to be going on in the machines, so why does the
> meaning need to be in the RDF - just the machines. Where is the meaning in
> the punched-card holes?

The meaning is tied to the hardware for which the card is designed. The
distinction we're arguing about is whether the card tells the machine to
store the negation of foo in some kind of useful in-memory
representation, or store the string "not foo". The latter is only useful
to machines that know they are supposed to parse the string and convert
that into a representation of the negation foo that they can actually
manipulate. But the card doesn't tell them that; it would be an extra
routine triggered by the hardware. That, I think, captures the
distinction between expressing and encoding.

> Ok, another line - let's say you've got this propositional stuff in place,
> common to A, B and C. But machine D wants to play snooker. Do you extend the
> common language to include the rules of snooker?

If you regard snooker as being worth expressing in a standard way. I
doubt the language would be very popular though. This isn't a very
useful analogy as we can choose all sorts of levels of detail and
expressiveness, according to our needs. 

> I can certainly see how ambiguity in the spec could cause problems, but not
> lack of functionality - if I have a triple representing 'pot the red ball'
> and I am machine D, I know what to do. If I am machine A, 'pot the red ball'
> has no meaning to me - so what am I going to do - 'pot the black ball'????

Machine A can correctly interpret the triple as an assertion with a
particular predicate, subject and object.  It doesn't know what it
should do, of course; this will always be the case with unknown
predicates etc. 

If we have a system that encodes negation and other logical concepts in
some way, machines that understand may retract triples, or carry out
other processing actions according to their interpretation of the
negation etc. i.e they can reason with triples about snooker, even
though they don't understand snooker.

Other machines will just store the triple analogy of the string "not
foo" and won't be able to do anything useful.


David Allsopp.

/d{def}def/u{dup}d[0 -185 u 0 300 u]concat/q 5e-3 d/m{mul}d/z{A u m B u
m}d/r{rlineto}d/X -2 q 1{d/Y -2 q 2{d/A 0 d/B 0 d 64 -1 1{/f exch d/B
A/A z sub X add d B 2 m m Y add d z add 4 gt{exit}if/f 64 d}for f 64 div
setgray X Y moveto 0 q neg u 0 0 q u 0 r r r r fill/Y}for/X}for showpage
Received on Tuesday, 10 April 2001 11:15:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:38:20 UTC