interpretations, time, and HTTP [was: checked RDF semantics...]

On Sat, 2002-12-14 at 01:31, pat hayes wrote:
[...]
> >| It assumes, implicitly, that urirefs have the same
> >| meaning whenever they occur.
> >
> >I think that overstates the case; the semantics only
> >assumes that each interpretation gives one denotation
> >to each uriref; interpretations corresponding to different
> >times might give different denotations to the same uriref.
> 
> No. How can an interpretation correspond to a time

Hmm... this seems so straightforward
to me that I must be missing something...

Consider: interpretation I1, which binds
	my:dan to me in the present
	my:age to A1
In I1, EXT(A1) is { <me in the present, 35> }

and interpretation I2 which binds
	my:dan to me ten years from now
	my:age to A2
In I2, EXT(A2) is { <me ten years from now, 45> }


or even simpler: in I1,
	my:thisYear denotes the year 2002
and in I2,
	my:thisYear denotes the year 2012

i.e. one interpretation might be the world
today, and another might be the world tomorrow.
Another might be the world as of some HTTP
request, and another might the the world as
of a later HTTP response.

> or the set of 
> interpretations change with time?

'the set of interpretations'... umm... I don't know what
to make of that... the set of all possible interpretations?
I don't suppose that changes over time (though my brain
hurts to think of what that set looks like).

> The truth conditions do not change 
> with time.

Right; of course not.

> What you say only makes sense if interpretations are 
> somehow defined to be temporally parameterized, but they aren't.

I'm not saying they're temporally parameterized; I'm just
saying that each interpretation is its own world, and
some of those worlds might be sorta like snapshots
of the the one we know and at different times.


> >WRONG.
> >
> >(this would need a different sort of test than
> >the ones in our test document, but I think it
> >could be observed objectively.)
> 
> I would like to see it.

umm... this goes well beyond what goes
in the RDF spec, but if you will,
consider a semantic extension that
binds my:now to the current time
(or perhaps the time when some request is received),
and includes a class :YearsBefore2010.
Then take the formula

	my:now rdf:type :YearsBefore2010.

It'll be entailed by the empty formula
this year, but not in 10 years.

Maybe this testing point is a total red herring...


> Heres an argument why not: suppose that 
> something is entailed by a graph at one time. Then it is entailed by 
> the same graph at any other time, since entailment makes no reference 
> to time (same applies to place, manner, person thinking about the 
> entailment, whatever). Any graph entails itself. So, any graph at one 
> time entails the same graph at any other time.

Yeah, but entailment is about stuff that works
for *all* interpretations.

I'm just saying that one interpretation might look
one way, and another interpretation might look another way.

> 
> >
> >| We do not make any assumptions about the relationship
> >| between the denotation of a uriref and a document or
> >| network resource which can be obtained by using that uriref
> >| in an HTTP transfer protocol.
> >
> >Again, that overstates the case. 'We' the formal semantics
> >editor don't make any such assumption.
> 
> Right, that is what is meant. Restate this to say 'the formal 
> semantics does not assume any. particular relationship....'
> 
> >But we the RDF
> >Core WG do expect that URIs will usually be used in RDF
> >consistently with their use in HTTP, HTML and other conventional
> >contexts.
> 
> Do we?? That is news to me. I was under the very strong impression 
> that we were not making that assumption, in fact, and that the use of 
> urirefs in RDF was not at all aligned with their use in HTTP or HTML. 

Perhaps I distracted you with the word 'consistently'...
I didn't mean it in its formal logical sense.
The formal semantics of RDF aren't constrained by HTTP nor HTML.

But informally, one can use HTTP and HTML to observe
that interpretations that satisfy
	<http://www.w3.org/> dublinCore:title "bananas"
are not very closely related to the world in which we live.

One can build semantic extensions of RDF that take
HTTP into account, is what I'm saying, I guess.

> There is nothing anywhere in RDF that assumes that a uriref has 
> anything at all to do with whatever happens when you use that uriref 
> in an HTTP protocol.

Well, there is for example this text in a draft of one
of the RDF specs:

"The social conventions surrounding use of RDF assume that any RDF URI
reference gains its meaning from some defining individual, organization
or context. This applies most notably to RDF predicate URI references. "
 --
http://lists.w3.org/Archives/Public/www-archive/2002Dec/att-0053/00-rc#section-authority


> We have discussed this issue at length several 
> times and nobody has ever suggested otherwise.


> >This is what the intro to the semantics says;
> >directly only briefly, but indirectly thru the concepts
> >doc more elaborately.
> 
> In that case, it seems to me that the docs as a whole say that RDF 
> does not in fact mean what the semantics doc says it means. If that 
> is really the case, then we should say so very clearly, indeed. 
> However, I wish that you had mentioned this earlier. This wording has 
> been in the semantics document unchanged now for many months, through 
> many edits and rewrites, and you have not had any problems with it 
> before.

Sorry, I didn't notice it. Note that I didn't label it WRONG.
I just said it overstates the case.

> And in fact the reason it is in there is because you, Dan, 
> told me explicitly to NOT try to take account of stuff like this when 
> doing the MT, but to treat urirefs as simple logical names.

Yes, as a formal matter, they're just logical names.
But we expect those logical names to get sorta
connected to the world in which we live via HTTP
and other communications mechanisms, as discussed
in the "Meaning of RDF" section of the concepts document,
right?


-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Saturday, 14 December 2002 04:00:26 UTC