Re: ACTION 2001-08-24#9 : issues with containers

pat hayes wrote:
> 
> >pat hayes wrote:
> > >
> > > >Jan Grant wrote:
> > > >[...]
> > > > > While I have held, in principle, what I'd characterise as
> >DanC's opinion
> > > > > here (or the more extreme version: "alt is totally broken")
> > > >
> > > >I'm not saying it's broken; I'm just saying it's not magic.
> > > >It's very mundane; from the MT perspective,
> > > >it means no more or less than any
> > > >other class (Apple, Bananna, Integer, ...).
> > >
> > > Then why bother even mentioning it in the M&S, let along spending
> > > pages on it?
> >
> >For the same reason that C programming books mention printf().
> >Yes, everybody could develop their own print routine
> >in vanilla C, but it's cost-effective for the community
> >to agree on a standard library of terms sometimes.
> 
> Well then let us refer to it in that way, ie as part of a 'standard
> library', rather than as part of the core language itself.

Very well.

> Right now,
> as I understand it, an RDF engine that did not handle containers in a
> particular way would not be in conformance to the M&S spec.

Nor would a C compiler whose runtime didn't include
printf() conform to the ANSI C spec.

The special handling is in the surface syntax only;
i.e. <rdf:_1> can be abbreviated <rdf:li>.

> >The widespread availability of printf() does not impact
> >the syntax and semantics of the C programming language
> >at all. It does, however, increase its utility significantly.
[...]

> >At its core, the language has *neither* construct.
> >It has only
> >       -- logical constants (URIs)
> >       -- existentially quantified variables
> >       -- two-place predicates
> >       -- conjunction
> >
> >That's it.
> >
> >Bag and Alt are just two logical constants.
> 
> That is a point of view, but it does not seem to be the one expressed
> in the M&S.

I think it is in there, though sorta hidden.
I hope the clarified M&S spec makes this view more clear.

But maybe others disagree; I dunno.


> I have no axe to grind here: I would be happy to banish containers
> and reification from RDF, myself. But I would like us to be clear on
> the matter. If they are part of the language, with an intended
> meaning, then the model theory - the definitive semantics of the
> language - should define that meaning as far as possible. If they are
> not part of the language then let's remove them from the language
> (and maybe have an explicit status for them as part of a 'library' of
> handy constructions). If they are part of the language but have no
> defined meaning, then let us say so, and be ready to smile fixedly at
> the mockery that would then be our due.

I like the library idea.

> > > It's
> > > not a question of 'magic', but of understanding why there would be a
> > > totally meaningless distinction built into the syntax.
> >
> >Just because the distinction is not specified in a model
> >theory doesn't make it meaningless.
> 
> I disagree. If the distinction is part of the syntax of the langauge
> specification, and it has an intended meaning, then that meaning
> should be reflected in the model theory. Otherwise the model theory
> is not a semantic theory of the language, in which case it is
> effectively useless. If a parser recognises a construct and treats it
> specially, then it ought to be at least mentioned in any semantic
> specification (if only to say that the semantics assigns it no
> particular special interpretation.)

I'm happy with a "no special interpretation" notice.

> >The distinction
> >between Apples and Bananas is not in the model theory,
> >but there is a distinction: in many interpretations,
> >their extensions are different.
> 
> Right, and the MT indeed shows what that claim means. It also,
> however, shows that one cannot actually state the distinction in RDF.
> But one can state the distinction between Bag and Alt, apparently;

in RDF? I'd be very surprised to learn that the distinction
between Bag and ALT can be expressed in RDF 1.0.

> so
> what does *that* mean, it seems reasonable to ask?

I think I'm lost at this point.

> > > This line amounts to treating all containers alike in the MT,
> >
> >exactly; which, I think, is why you were actioned to remove
> >containers from the MT altogether.
> 
> That was not my understanding.
> 
> Can anyone clarify this point? Was there a consensus that the MT
> treatment of containers was wrong or inadequate?

Perhaps I overstated the case; I don't think there was
any decision of that sort...

> My understanding was simply that the action to remove containers and
> reification from the version of the MT in the working paper was
> because it was felt that there were open issues at this stage;

That much is so...

> but
> that once these issues were resolved, that the model theory could be
> extended to the entire language. Is that understanding incorrect?

I don't think anyone can say for certain yet.

> (Or is the point that there is no *need* to mention containers
> explicitly, since if this is all they amount to, then they have no
> extra semantics over and above that which arises from the core RDF
> meaning of rdf:_n in any case?

That's my understanding.

> If so, I would suggest that it would
> do no harm to mention them in the model theory document, if only to
> emphasise that the MT makes only this minimal assumption, and does
> not mandate any of the 'distributive' meanings discussed at such
> length in the M&S. )

That's fine with me.


> > > ie they
> > > are thingies that have elements which are accessed by applying rdf:_n
> > > to them, and that's all.
> >
> >Yes!
> 
> OK, but we can put that in the model theory. In fact it is there now,
> without the 'and that's all'. It really amounts simply to some domain
> restrictions on rdf:Bag, rdf:Alt and rdf:Seq (ie that they are
> disjoint), but that isn't otherwise expressible in RDF, so it is a
> genuine extension to the language.

Good point.

> (There is also the business of
> there being a default first member of any alt, but I can't handle
> defaults in the MT, I confess.)

Yeah; who knows what to do with that.

[...]
> >Just not in the core model theory.
> 
> But why on earth not do so, if we can do it?

OK, to a certain extent, a treatment of containers is probably
in order, eventually.

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

Received on Tuesday, 4 September 2001 20:42:53 UTC