Re: summary of status with respect to datatypes

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


"Peter F. Patel-Schneider" wrote:
> 
> Given that Frank doesn't seem to have produced one of his excellent
> summaries for this week's teleconference, let me give it a try.  I will also
> include some summarization of the meeting in Washington.
> 
> The situation with respect to datatypes appears to contentious over two
> issues:
> 
> 1/ Whether the datatype is required to be given along with the lexical
> representation, or is permitted to be given along with the lexical
> representation, or is forbidden to be given along with the lexical
> representation.
> 
> 2/ Whether there is one (direct) relationship between an abstract object
> and a datatype value or several, one going to the lexical representation
> and another (or others) going to the value itself.
> 
> There were three proposals that had been put forward:
> 
> A/ An older proposal by Ian and myself of several weeks ago, at
>    http://www.cs.man.ac.uk/~horrocks/daml+oil/Datatypes-jan-01
> B/ The proposal by Dan Connolly at http://www.w3.org.2001.01.ct24

er... rather http://www.w3.org/2001/01/ct24

> C/ The current proposal by Ian and myself, prepared last week, at
>    http://www.cs.man.ac.uk/~horrocks/daml+oil/Datatypes/
> 
> They stack up in the following manner:
> 
> Proposal            Issue Status
>                 1               2
> 
> A               permit          one

Just one?
A doesn't allow that if there's a relationship between,
say, x and y, and another between y and z, that
there's another relationship between x and z? How
does it achieve that?

Perhaps you meant something by "direct" that
I don't understand?

> B               forbid          several

no, giving the datatype inline not forbidden; it's explicitly
licensed:

[[[
So that the value corresponding to the numeral 10.0 can be written

<xsd:decimal xmlns:xsd="http://www.w3.org/2000/10/XMLSchema#">
 <rdf:value>10.0</rdf:value>
</xsd:decimal>
]]]

--        Using XML Schema Datatypes in RDF and DAML+OIL
http://www.w3.org/2001/01/ct24
Thu, 15 Feb 2001 22:23:12 GMT

that example is equivalent, by the definition of RDF syntax,
assuming the same namespace declarations in effect, to:

<xsd:decimal rdf:value="10.0"/>

That example has been in ct24 since
revision 1.5 date: 2001/01/12 03:56:32.

> C               require         one
> 
> So far, nothing should be too controversial

Well... except that your summary of B has little resemblance
to what I wrote.

> Now for some (perhaps) more contentious summarization:
> 
> At the meeting in Washington, there was general agreement that the proposal
> by Ian and myself was the way to go.

Right... at the time, I didn't see it as inconsistent with
my proposal; I didn't realize that allowing folks to state
other interesting constraints (like the relationship between
a property that takes a decimal and a property that
takes the corresponding numeral) introduces unacceptable
issues w.r.t. decidability. (I gather Ian provided a
reference, for the minutes of our last meeting, to the technical
details, for which thanks; I look forward to
studying it.)

>  Ian and I revised the proposal to the
> current proposal above.  After considerable discussion at this week's
> teleconference a decision to go with the current proposal, ``as the best we
> can do right now''.

Right; with a note in the spec calling out the issue.

>  To that end Ian, Frank, and I are revising the example,
> walkthrough, and reference documents to result in a complete proposal.

It's fair to say "... in a complete revision of the
spec this group is producing." No need to call it
a proposal any longer.

Many thanks, by the way.

> The example and walkthrough have gone through an initial round of editing
> and are available at the website above.
> 
> Peter Patel-Schneider

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