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

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

>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.
>
> > The M&S doesn't seem to feel a compulsion to go on and
> > on about recommended uses of Bananas.
> >
> > > > - that is,
> > > > that an app can infer what it likes, an alt-unaware MT is going to
> > > > produce an odd semantics for something like
> > > >
> > > >      <doc1> <dc:creator> _:a .
> > > >      _:a <rdf:type> <rdf:Alt> .
> > > >      _:a <rdf:_1> <jan> .
> > > >      _:a <rdf:_2> <dan> .
> > > >
> > > > ("doc1 was written by either jan or dan") - I don't see how you can
> > > > ignore alt in the MT and get this interpretation, no matter how you go
> > > > about it.
> > >
> > >I interpret that n-triples fragment not as "doc1 was written
> > >by either jan or dan" but
> > >
> > >  doc1's has a creator value which is a collection including
> > >  jan and dan; this collection is the sort where folks conventionally
> > >choose
> > >  one from the collection, rather than using all of them.
> > >
> > >Again, suppose the graph had a Bag rather than an Alt:
> > >
> > >      <doc1> <dc:creator> _:a .
> > >      _:a <rdf:type> <rdf:Bag> .
> > >      _:a <rdf:_1> <jan> .
> > >      _:a <rdf:_2> <dan> .
> > >
> > >We don't license the inference that
> > >       <doc1> <dc:creator> <jan>.
> > >in that case, do we? No. Then why should rdf:Alt have any magic
> > >associated with it?
> >
> > Because that is what the M&S seems to imply, seemed to me; and
> > because if we can't infer anything different from its being an Alt
> > than a Bag, why does the language have both constructs in it?
>
>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 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.

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

>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; so 
what does *that* mean, it seems reasonable to ask?

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

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; but 
that once these issues were resolved, that the model theory could be 
extended to the entire language. Is that understanding incorrect?

(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? 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. )

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

>
> > The only differences between bags and seqs
> > and alts is that they are different by stipulation, ie nothing can be
> > both of them at once.
> >
> > However, if we do say this, then it seems question-begging (and
> > intellectually dishonest) to go on to say that some aspect of meaning
> > is 'conventionally' this or that, when the language itself doesn't
> > support that 'conventional' interpretation. In other words, we are
> > saying that it *does* mean something, nudge nudge wink wink, but *we*
> > aren't going to come out and say what it does mean, for some reason.
>
>Just not in the core model theory.

But why on earth not do so, if we can do it?

Pat


>
> > (Not that we couldn't: we can, in fact, but we are refusing to, for
> > some reason, probably because ... well, I cannot think why, to be
> > honest. )
> >
> > This seems to me to be exactly the wrong way to set up a useful
> > semantic-web information interchange language.
>
>--
>Dan Connolly, W3C http://www.w3.org/People/Connolly/

---------------------------------------------------------------------
(650)859 6569 w
(650)494 3973 h (until September)
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Tuesday, 4 September 2001 19:16:40 UTC