Re: Draft Partitioning

Mike's http://www.daml.org/language/features.html
gives an excellent "Language Feature Comparison"

--
Jos





Frank Manola <fmanola@mitre.org>@w3.org on 2001-06-18 07:21:54 PM

Please respond to fmanola@mitre.org

Sent by:  w3c-rdfcore-wg-request@w3.org


To:   Brian McBride <bwm@hplb.hpl.hp.com>
cc:   w3c-rdfcore-wg@w3.org
Subject:  Re: Draft Partitioning

Brian McBride wrote:
>
> Frank Manola wrote:
snip
> > This starts to get into the basis of my comment at the telecon, that we
> > might want to include some stuff currently in Schema in these
> > descriptions.  I was specifically thinking of some of the ideas
> > discussed in Section 2.1, and the core classes described in Section 2.2,
> > of Schema.
>
> Is the motivation for this suggestion to get a better modularization?

Better modularization, and more precision as to our intentions.  One way
of interpreting RDFS is that it's one of a possible collection of schema
specifications for RDF (much as XML Schema is one of several schema
specifications for XML, another being DTDs).  Under this interpretation,
you can write RDF without using RDFS.  But can you really?  It seems to
me that the M&S formal model, when it talks about "sets" called
"Resources", "Literals", "Properties", and "Statements", is trying
(unnecessarily, or at least without any reason that I can see) to avoid
saying simply that RDF has these as built-in classes, as (mostly)
described in Schema Section 2.2.  Conversely, Schema Section 2.2 says
"Every RDF model that draws upon the RDF Schema namespace (implicitly)
includes these [core classes]."  But, when you look at the formal model
in M&S, so apparently does every other RDF model, whether there's a
schema around or not (either that or the M&S formal model is talking a
group of sets that are distinct from any of the core Schema classes, but
which, confusingly enough, have the same names).  [NB:  I noted in
another context that M&S doesn't define a concept of a "set" anyway,
which is another difficulty in using the term here.]

>
> > Section 2.1 (correctly) notes the similarity of the RDF
> > schema type system to that of object-oriented programming languages,
> > starting off with some built-in types (or classes) like "resource",
> > "class", "property", and their relationships, and then allowing for
> > user-defined types/classes.  Those built-in types and their
> > relationships (I claim) ought to be part of the model (or abstract
> > syntax) specifications (I don't insist on subclasses or subproperties;
> > just the basics).
>
> Are you suggesting that the Abstract Syntax and Semantics [need to be
> careful about that acronym] as suggested in the draft partition CANNOT
> stand alone without notions of type, Class etc?

Generally, yes.  The M&S already uses the notion of type, and really
uses the notion of Class too (although it uses the word "set", I think
that's just to enable postponing introducing "Class" until the schema
spec.;  if there's an intended difference in meaning, I'd like to know
what it is).  One of the things we need to decide is how much (and what
kind) of a built-in type system we want to assume for RDF.  I agree that
we don't want to put too much in the ASS, since a SmallASS provides more
flexibility [I mean, for development of type systems that may not look
like RDFS, of course!].  However, my principle is that I don't mind
having a BigASS if that's what it takes to avoid having a DumbASS.

>
> If you are suggesting that the step all the way from ASS as in the
> draft partition proposal to schema is too big and to break that up
> into two layers - built in typing and then user defined typing, I
> wouldn't disagree with you.
>
> I suggest there is value in identifying a base layer which is
> minimal on which everything else could be built.  Right now I don't
> expect that MUST include concepts of type, Class etc, but I could
> be proved wrong.

I agree.  It's just that I think the concepts of type (or Class), and
specific classes like Statements, are in the base layer already.  It's
just that we seem to want to avoid calling them "classes" in M&S for
some reason (we call them "sets" instead), only to turn around first
thing in Schema and say "you know those sets foo and bar and ... we
talked about in M&S?  Well those are the classes foo and bar and ...
here."  I don't see the point in doing that.  I can see that some care
is need in making this partition to avoid overconstraining things.
Perhaps those who were in on the earlier partitioning between M&S and
Schema could share some of the ideas they were kicking around here.

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

Received on Tuesday, 19 June 2001 04:35:17 UTC