Re: added diagrams to "Using XML Schema Data Types..."

From: Dan Connolly (connolly@w3.org)
Date: 02/07/01


"Peter F. Patel-Schneider" wrote:
> 
> From: Dan Connolly <connolly@w3.org>
> Subject: Re: added diagrams to "Using XML Schema Data Types..."
> Date: Wed, 07 Feb 2001 11:23:18 -0600
> 
> > "Peter F. Patel-Schneider" wrote:
[...]
> > > I would be much happier with a solution that had a single property, namely
> > > size, that mapped directly into a datatype.  I don't see any benefits from
> > > having these multiple properties; only disadvantages.
> >
> > The advantage is that parsing formulas (RDF documents)
> > remains independent of other stuff, including trust issues.
> >
> > Otherwise, if I put the range(size, Decimal) information in
> > in file X, and then I <size>10</size> in file Y,
> > the interpretation of Y depends on whether I have seen
> > (or believed etc.) file X. That doesn't seem workable to me.
> 
> Either you trust the definition of a property or you don't.  If you don't,
> then you don't get to use the information therein, and lots of things may
> break.  If you do, you do get to use the information therein, and
> everything should work.  As far as timing goes, if you don't have
> information on how to parse some input, why not defer the parsing until you
> have more information?


I'm not sure what you mean by "the definition of a property".
Do you mean that there's always exactly one such definition?
how much stuff goes in a definition? I know what documents
are and I know what statements/formulas/assertions are.
Maybe I can read "a document containing statements relevant
to some property" in place of "the definition of a property."

As to why not defer parsing... a major goal of all this
logic-and-the-web stuff, to me, is a certain sort of scalability
where we can analyze documents independently, see
what they mean (i.e. what formulas they state) and then
merge information from multiple documents in a monotonic
fashion. This is a major feature of RDF. It's something I
would require even if we threw out RDF syntax and started over
with XML and URIs.

To have the parsing of one document depend on the
contents of another conflicts with that goal/principle.

Another way to state this principle is that
the knowledge contained in two documents, X and Y,
is always the conjunction of the knowledge in X with
the knowledge in Y. To allow X to change what Y says
in some non-monotonic way doesn't seem scalable/workable
to me.



> In particular, it seems to me that your proposal has exactly the same
> problem.  You also depend on external information on how properties should
> work.

But the various bits of information accumulate in
the normal monotonic fashion; I don't have
the situation where I initially parsed it as
a string, but then I discover I was wrong or something
and I have to undo stuff.

> > > Further, it appears to me that Dan's proposal breaks RDF in a very
> > > significant fashion, requiring literals (or at least datatype values) to be
> > > the source of properties.
> >
> > I don't see this as breaking RDF. It's always been
> > the case that you could look at the string "xyz"
> > as the resource data:,xyz and use it as the subject
> > of an assertion.
> 
> Where is this described/defined?  How is the URI ``data:,xyz'' related to
> the RDF literal xyz?

RDF literals are a little underspecified, but assuming
we agree that the RDF literal xyz is nothing more
and nothing less than sequence
of the 3 characters x, y, z, then that's what data:,xyz is
specified to denote as well;

Data: URL scheme, L. Masinter, August 1998.
ftp://ftp.isi.edu/in-notes/rfc2397.txt

(cited from our handy index of URI schemes
http://www.w3.org/Addressing/schemes#data )

Maybe this is a somewhat creative interpretation.
But again, from my perspective, it doesn't seem to
conflict with the way RDF works.

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
office: tel:+1-913-491-0501
pager: mailto:connolly.pager@w3.org
  (put return phone number in from/subject)


This archive was generated by hypermail 2.1.4 : 04/02/02 EST