Re: Reification as nesting

>   [Drew McDermott]
>   >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]]
>
>   [Pat Hayes]
>   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]
>
>I don't think this is any more "rigorous";

Bad choice of word, sorry.

>it might be more
>consistent, but I think most semantic-net hackers have been willing to
>treat binary relationships differently from n-ary relationships.

Well, OK, if that is thought acceptable. There has been a lot of 
traffic wanting 'simple' RDF to be preserved as a subcase of anything 
more ambitious, and I was trying to do that smoothly.

>   [Drew McDermott]
>   >It is indeed impossible (or highly artificial) to give [etc melanie
>   >ashley] a coherent meaning.
>
>   [Pat Hayes]
>   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.)
>
>   ...
>   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'.
>
>I don't think it's specifically an RDF requirement that every
>subexpression must have a "full ... meaning"; it's just compositional
>semantics.  If [etc a b] is not a subexpression of [R c [etc a b]],
>then we should just admit we're allowing n-ary relations into the
>language, and go to [R c a b].

This may be the misunderstanding noted in another message, but I was 
trying to find a way to encode things like [R c a b]  *as* a set of 
triples, which was the reason for the [R c [etc a b]] encoding. (OK, 
it was broken and Seth has fixed it, but that was the goal.)

>I agree we need terms in RDF.  But declaring that some "triples" are
>terms, or fragments of terms, seems like too big a departure from the
>current language.  For a triple to be a triple in the current sense,
>it must be an assertion (or be an assertion when bindings of its free
>variables are supplied).

That is true currently, but that is exactly what Im trying to suggest 
we weaken. Allowing some exceptions to that wouldnt require changing 
the triples: everything could still be a set of RDF-like triples, but 
some of them couldnt be interpreted as assertions. Seems to me that 
introducing contexts or quads or whatever are all much bigger changes 
to the RDF model than introducing what amounts to a new category of 
triple (or just changing the spec so that some of the old triples 
have a different interpretation.)

> Any term that isn't of the form
>predicate(a,b) should be dealt with by describing it in terms of
>triples.

Careful... that 'describing it' sounds awfully like reification. (If 
it doesnt mean that, then can you spell out how the decribing works? 
If it does mean that, I don't want to go there, for reasons that 
would make my fingers ache to explain again.)

>We can always provide syntactic sugar that allows a more
>concise representation for human consumption.

Sure, but truth predicates are not syntactic sugar.

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 Friday, 8 June 2001 14:55:07 UTC