- From: David Allsopp <dallsopp@signal.dera.gov.uk>
- Date: Thu, 17 May 2001 12:18:32 +0100
- CC: www-rdf-logic@w3.org
pat hayes wrote: > Well, the central puzzle to me in RDF at present is that > RDFeification seems to be used for (at least) two very different > purposes, and maybe both are needed, so my suggestion would be to > find a way to distinguish them. The two purposes are (1) as a > data-structuring technique, especially to create complex expressions > out of subexpressions, ie as an abstract-syntax construction device; > and (2) as genuine reification, ie as a way to write expressions > which denote/refer to/mean other expressions. The RDF literature > seems to intend that RDFeification should have the second meaning, > but most of the actual uses of it seem to use the first. Are these in fact the two uses in the RDF Model and Syntax? A) Reification is introduced (in section 4.1) in order to make statements about other statements, for the purpose of using a statement without asserting it (Ralph says that Ora is the creator of http://foo/bar...). B) A second usage is then introduced: that of representing groups of statements that form part of the same rdf:Description. These are statements which _are_ asserted; they are reified just so the association between them can be expressed, not because we want to avoid asserting them. [Are we not still making statements about statements here, i.e. saying that each statement belongs to a particular collection?] > >As I understand it, you attach a timestamp property to the message > >object (a resource of type Message); but I'd assume that we intend to > >say that the timestamp applies to all individual statements within that > >message. > > > >If so, how are these statements (the actual message content) 'contained' > >by the message object, since it can't point at them without reification? > ---- ) > > David seems to be clearly thinking of 'reification' here simply in > terms of pointers to access a subexpression. Now, the use of > labelled triplet structures to encode graphs, and hence graphically > representable datastructures, and hence abstract syntax, is all > accepted good work practice in software design, and has been for many > years. However, that usage is of type (1), not type (2). I'm glad I appear to be thinking clearly; I'm not so sure myself 8-). My intent above is a little confusing in this context; What I want to do is say things about individual statements (the time they were made, and by whom); which seems to me to be usage (2). However, the idea of Jim Hendler's was to have the statements 'within' a message; we would then make statements about the message resource (again; time, origin), but which implicitly apply to all the constituent statements, because they happen to have the same origin and time; it is up to our application to interpret this correctly (effectively, by somehow distributing the time and origin over all the statements). However, in order to achieve this, one has to indicate that the individual statements belong to the message or are contained within it. This could be achieved by reification, but that's usage (1). The intent is still to say things about statements, but we 'factor out' the <timestamp, origin etc> which is the same for all the statements within the message (this is the idea of Contexts in RDF?). So we get a very mixed usage; using type (1) to achieve type (2) in a more obscure way! (In fact, Jim then suggested a method that avoids RDF reification at all...). Having gone through all that, I'm unclear whether there really is a difference between the two usages here, since usage (1) is a way of gather statements together, but only in order to say something about each of them, which could be achieved by usage (2), saying something directly about each statement...8-( Regards, 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 Thursday, 17 May 2001 07:22:53 UTC