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".  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?

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.


> 
> 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.

--Frank


-- 
Frank Manola                   The MITRE Corporation
202 Burlington Road, MS A345   Bedford, MA 01730-1420
mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-875

Received on Thursday, 25 October 2001 12:05:10 UTC