Re: Reification as nesting

>   [Tim Berner-Lee]
>   Let's see... below you use a triple as an item in a triple.
>
>   [a b [c d e]
>   which one can assume is shorthand for
>
>	 [a b _g]
>   _g  [c d e]
>
>   with anonymous _g.  So you have triples with addresses, or a restricted
>   form of quad.
>
>How about we indicate the 4th component of a tuple in one of two ways:
>-- Write it after a slash
>      [a b c]/nest-id
>
>This emphasizes that the role of the nest-id is for grouping what
>would otherwise be triples.
>
>-- Put a bunch of triples inside curly braces, in which case they all
>have the same 4th component, exactly which is unimportant.  So
>
>    [a b {[a1 b1 c1], [a2 b2 c2], [a3 b3 c3]}]
>
>would be short for
>
>    [a b b966]/top
>    [a1 b1 c1]/b966
>    [a2 b2 c2]/b966
>    [a3 b3 c3]/b966
>
>   This is more or less  what happens in N3,  except that a 
>statement itself is
>   not surfaced as an extra type in the language. The (ugh) nest is.   You can
>   easily identify a statement by giving a nest with only one statement in it.
>   It can be a subtype of nest, if you like.  This reduces the 
>number of things
>   in the language, which makes it simpler.
>
>I believe asserting nests instead of triples does make sense, although
>one could always coerce a triple to a singleton nest.

True. However, if a nest is an encoding of a more complex sentence in 
some 'higher' language 'on top of' RDF, then of course asserting the 
nest makes sense in that higher language. It might or might not make 
sense to RDF itself (probably not), but so what?

>   [Pat Hayes]
>   > 'etc' means a continuation of whatever structure it occurs in, in
>   > this case a relational sentence with more than two arguments. Again,
>   > it would be natural to allow things like [... a b c d] as an
>   > abbreviation for [....a [etc b [etc c d]]].
>
>   [Tim Berners-Lee]
>   Yes, "etc" is a useful kludge.  Does it work?  i'm not sure, as
>   I before I could say yes I would want to feel that the predicates and
>   nestings had well-defines meanings.  For example, what is the object
>   of Q?  The statement etc(a,b)?  Not really.
>
>I find etc dubious, too.  The traditional way to introduce
>multi-argument functions into RDF would be to write
>
>   [statement33 rdf:type love_triangle]
>   [statement33 winner melanie]
>   [statement33 won ashley]
>   [statement33 loser scarlett]
>
>rather than
>
>   [love_triangle scarlett [etc melanie ashley]]

Yes, that is the more traditional RDF approach, along the lines of 
how it handles containers; although if the RDF M&S is taken 
seriously, then  'statement33' would be better written 'event33' or 
'fact33' or something like that. However, this approach, if carried 
through rigorously, would mean that a simple 'naive' RDF triple 
assertion [s V  o] should also get the same treatment, ie it should 
be rewritten in the form
[fact19 rdf:type V]
[fact19 somethingLikeSubject s]
[fact19 somethingLikeObject o]
and one of my guiding principles was to find an encoding of 
more-than-naive triples which left naive-triples completely alone, 
and still had them as a special case, ie that the extended language 
on top of RDF could retain current RDF as a subset.

>It is indeed impossible (or highly artificial) to give [etc melanie
>ashley] a coherent meaning.

I think you mean, to give it a coherent meaning in isolation, ie out 
of context, right? But that is precisely what I would not want to do. 
The current RDF model in which every triple must have a full RDF 
meaning regardless of its context is precisly what I am trying to get 
past, since it makes it impossible to express more complex syntax 
within RDF (without cheating of one kind or another.)

>We could take it literally to mean
>"pair" or "cons", and make love_triangle a predicate on a person and a
>pair of persons, but that would require interpreting some triples as
>terms rather than statements.

Right. When we use triples to implement more complex syntax, some of 
them ARE terms. Some of them, in fact, are not even fully-fledged 
syntax of any kind, but are only pieces or fragments of larger 
well-formed expressions I see no harm in this as long as we can 
clearly recognise such things. In this scheme they are precisely the 
ones that start with 'etc'.

Pat

---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Thursday, 7 June 2001 15:32:08 UTC