Re: Properties not predicates (was Re: PRIMER: draft data model section)

>Pat Hayes wrote:
>
>>>>....
>>>>
>>>>>>   o a statement is an abstraction; its a tuple with three 
>>>>>>components, subject,
>>>>>>
>>>>
>>>>If distinct tuples are identified by three distinct components, then
>>>>however many times I write the same three components down, I've still
>>>>stated only one tuple.
>>>
>>>
>>>>Is a triple identified only by its components,
>>>>or by something else too?  If I say "Frank is confused" 500 times, have
>>>>I made 500 (true) statements, or only one?
>>>
>>>
>>>
>>>This sort of discussion can rathole deep and long.  I've seen it 
>>>many times before on rdf interest and elsewhere and never get 
>>>anywhere.
>>
>>
>>Well guys, this was kind of settled long, long ago. We have the 
>>terminology. The 'concrete' things - of which there are 500 in 
>>Franks example - are called 'tokens' (as in 'word token', 'sentence 
>>token', and I guess for us 'triple token') and the 'abstract' 
>>things are called, unfortunately, 'types'....OK, lets not go there. 
>>Let us just agree that when we don't say 'token', and when it 
>>matters, we always mean the abstract thing. So, with that 
>>understanding, there is ONE English sentence "Frank is confused", 
>>no matter how many times tokens of that sentence get said, written, 
>>emailed, whatever.
>
>
>I agree;  there certainly is terminology to reflect these 
>distinctions, although I've seen different terms used, e.g., Curry 
>uses "inscription" for Pat's "token", "sentence" for Pat's 
>"sentence", and "statement" for (roughly) "the meaning of a 
>sentence".

Yes. Often people use 'proposition' for the meaning, as well. I like 
'inscription' , terrific word. Seems to suggest chisels and gold leaf.

>As Pat says, as long as we're consistent in our terminology, there 
>isn't a problem (I think it only becomes a rathole when we don't 
>identify the distinctions we need to make, and agree on separate 
>terms for them).  But we were talking about how we read the M&S, and 
>I still think the M&S can be read as saying that statements are 
>(roughly) triples (as opposed to consistently making the distinction 
>we've been talking about).  So what's the terminology we're agreeing 
>to use?
>
>1.  abstract thing: "statement";  concrete thing:  "triple"
>2.  abstract thing: "triple"; concrete thing:  "triple token" 
>(discourage use of "statement")
>3.  something else?

Of these, I like 1. better and I bet it will produce more readable 
prose, but we will have to take some care to explain the distinction 
and not just assume that the reader knows what we mean. We can always 
toss in the 'token' for emphasis at critical points.

>The point is, we're in the process of writing stuff (*I* certainly 
>am), and that writing ought to use the proper terminology to reflect 
>the distinctions we need to make.

Having made all this fuss, I have to admit that almost all the time 
it really doesnt matter, since you can read almost anything said 
about languages in either way and it makes sense both ways. It only 
gets nasty when you get into things like reification, and you have to 
say what those reifications are really *about*. So maybe our attitude 
when writing should be to not be too pedantic, but just be ready to 
make the distinctions when we need to. We can always say things like 
"in this section we use 'triple' to refer to a concrete syntactic 
token (or inscription) rather than the general class of triple 
expressions" , and maybe toss in some sentences about why we are 
suddenly being so persnickety about it.

>
>>
>>The only thing we have to bear in mind is that these abstract 
>>things really are *abstract*. You can't put them into computers or 
>>email them or point to them, or anything like that. So reifying one 
>>of these doesn't get you very far.
>>
>>When it comes to graphs, unfortunately for Brian's peace of mind, 
>>there is an exactly similar possibility of confusion. For example, 
>>can two different graphs be exactly isomorphic? If 'graph' means 
>>something like a token, then yes, obviously. If it means something 
>>like a mathematical abstraction, then no; being isomorphic is what 
>>makes it the same graph. (Really, the SAME graph.) Ive been taking 
>>'RDF graph' to refer to the token sense until now, and thinking of 
>>these graphs as something like datastructures. It makes sense to 
>>talk of copying a graph, for example, with this reading. However, 
>>to follow my own advice above, I ought to really call these 'graph 
>>tokens'.
>>
>
>
>Same comments apply to graphs, as Pat suggests.  Again, what 
>terminology are we agreeing to use?  We're going to have to talk 
>about graphs a lot, both in the abstract and the concrete senses 
>(e.g., copying graphs, shipping them around, merging them), and 
>we're going to have to try to use unambiguous terminology in writing 
>that material.

Again we only need to be careful when we need to be. (Sometimes logic 
just does it for you.). Actually I think that people will be more 
used to the type/token idea for graphs than they will be for 
languages in many cases, its the difference between a mathematical 
graph and a particular datastructure, and people are used to using 
'graph' for both. Again, as long as we spell out our assumptions when 
they matter, I think we needn't be too pedantic in our usage.

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, 25 October 2001 19:44:52 UTC