- From: <Patrick.Stickler@nokia.com>
- Date: Wed, 28 Nov 2001 18:18:18 +0200
- 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 UTC