RE: No model theory for reification?

>I think I was advocating a substantially more woolly position than you
>appear to want.
>
>A few inline comments follow ...
>
>>
>>
>>  saying they're to be used 'for this purpose' (provenance and quoting)
>>  doesn't adequately describe the meaning of these constructs. What *is* an
>>  instance of rdf:Statement? We need to give a clear answer, rather than
>>  allude to possible uses for the class. That's the mistake the old spec
>>  fell into (cont. below).
>
>Words typically have more than one (related) meaning falling into different
>usage patterns. It works in natural language, I have yet to be convinced
>that giving (not particularly formal) definitions that follow the
>"provenace" model and the "quoting" model is not a solution.
>
>e.g. when discussing the provenance of an RDF statement:
>
>1: A different resource is used for each occurrence of the statment.
>2: The resource is of type rdf:Statement
>3: The s/p/o properties are as follows: [ omitted ]
>4: dc properties are used to describe provenance.
>  [I am not suggesting (4) is correct, merely an example]
>
>This sort of resource is referred to as a "stating"
>
>when quoting
>Each rdf:Statement resource is uniquely identified by its s/p/o.
>
>This sort of resource is referred to as the Statement.
>
>We observe that each stating as a natural Statement corresponding to it.
>
>While it may seem confusing to have both Statements and Statings represented
>in the same way, in practice context will disambiguate.

This seems to me to be the central problem. *How* will 'context' 
disambiguate? What context, in any case? If RDF had contexts, it 
would be a different language.

The trouble with this kind of approach (not to reification in 
particular, but more generally) is that if there is no way in the 
language to state a distinction, and if the same constructs are used 
to say different kinds of things, then confusion will be inevitable. 
Maybe some people will manage to get by, but someone else will be 
confused (or, worse, some other piece of software will get confused.) 
Surely it is better to provide a way to state or somehow indicate the 
distinction, and allow both kinds of things to be said more clearly. 
If you want strict backward compatibility and don't like new 
syntactic conventions, then make the one you like best be the 
unmarked case and mark the other one.

>  >
>>  How so? Giving a clear definition for rdf:Statement, rdf:predicate,
>>  rdf:object and rdf:subject might avoid the stating/statement problem.
>
>It is clear to merely say that the rdf:Statement corresponds to the triple
>in n-triple and the rdf:subject is the first field, the rdf:predicate is the
>second, the rdf:object is the third.
>
>Clarity only vanishes when we claim some deep metaphysical truth about
>*identifying* a triple with its reification. If the reification merely
>models the triple then it is not difficult.

No, its still a problem. There are at least two distinct senses of 
'model a triple' involved here, and you have to choose one of them. 
Other people will understand you to be meaning the other sense, 
however, and will draw conclusions you didn't intend.  Even if you 
only want to use RDF for some private purpose, we have to make it 
capable of being published on a web and 'understood' by people/agents 
who have no way of knowing what we had in mind when we wrote it.

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, 24 January 2002 12:06:13 UTC