W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > November 2001

RE: Proposal to drop S from consideration

From: <Patrick.Stickler@nokia.com>
Date: Wed, 28 Nov 2001 18:18:18 +0200
Message-ID: <A03E60B17132A84F9B4BB5EEDE57957B07F4E3@trebe006.NOE.Nokia.com>
To: connolly@w3.org, jjc@hplb.hpl.hp.com
Cc: w3c-rdfcore-wg@w3.org


> -----Original Message-----
> From: ext Dan Connolly [mailto:connolly@w3.org]
> Sent: 26 November, 2001 16:36
> To: Jeremy Carroll
> Cc: Stickler Patrick (NRC/Tampere); w3c-rdfcore-wg@w3.org
> Subject: Re: Proposal to drop S from consideration
> 
> 
> Jeremy Carroll wrote:
> 
> > I feel Patrick has raised some legimate issues here.
> > 
> > Principally, I understand his message as a vote in the 
> "cannot live with"
> > category against S; with a coherent explanantion of why: backward
> > compatibility.
> 
> 
> All of my code and all of the code I've seen from other apps
> assumes that the object of
> 	<dc:title>abc</dc:title>
> is a string of 3 characters. S is completely backwards
> compatible with this.

Great. I'm glad the you personally don't have any issues
with the S proposal and won't be impacted by incompatabilities.

But that doesn't mean that other's won't.

And while I don't take issue with your interpretation of

  <dc:title>abc</dc:title>

such that 'abc' denotes a string, but you seem to imply
(and please correct me if I'm wrong) that given

  <dc:date>2001-11-27</dc:date>

that '2001-11-27' also denotes a string, which I think
is not the common view (certainly not my view). I think
that most folks expect the data content of such a property
element to correspond to a value in a value space, and that
the data content literal correlates to a lexical form, not a
string. 

The string representation of the literal is just a 
syntactic mechanism, not the actual semantics of the literal.
The literal is a lexical form, not a string.

> > I am increasingly concerned about how many changes we feel 
> entitled to make
> > under our charter.
> 
> 
> 
> You see S as a change? I don't. It's the way I've read
> the RDF spec since 1997 or so.

I definitely see S as a change, not only a change of common
idiom but also requiring changes to how one thinks about
property relations and the semantics of RDFS mechanisms.

The S proposal would require re-definition of the semantics
of (and possible constraints on the use of) rdfs:subPropertyOf,
rdfs:range, and rdfs:domain to prevent ambiguous overloading
of semantics for properties such as

   ex:age rdfs:subPropertyOf xsd:integer .
   Bob ex:age "10" .

Where the property ex:age suggests that Bob is an integer.

I see the S proposal as initiating a domino effect of
changes, redefinitions, clarifications, and constraints
that otherwise would not be needed if a combined P/U/DAML
approach were adopted, as I've proposed, and the latter
approach will address the needs of data typing and support
of XML Schema data types equally well as the S proposal
(possibly better, given backwards compatibility both with
common idioms as well as common understanding of present
RDF/S semantics).

Regards,

Patrick
Received on Wednesday, 28 November 2001 11:18:26 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:42:46 EDT