RE: Proposal to drop S from consideration

Firstly, let me apologise to the WG for being so
vocal and expressing my opinions and concerns so
freely despite having so recently joined the WG.

My intent is not to "stir things up" but to (hopefully)
contribute to a better RDF.

That said...

> -----Original Message-----
> From: ext Dan Brickley [mailto:danbri@w3.org]
> Sent: 22 November, 2001 12:25
> To: Stickler Patrick (NRC/Tampere)
> Cc: w3c-rdfcore-wg@w3.org
> Subject: Re: Proposal to drop S from consideration
> 
> 
> On Thu, 22 Nov 2001 Patrick.Stickler@nokia.com wrote:
> 
> >
> >
> > The S proposal adds unneeded machinery, seemingly requires
> > redefinition of the semantics of rdfs:subPropertyOf in terms
> > of data type properties versus non-data type properties, and
> > requires a treatment of data typing that is incompatible with
> > current usage.
> >
> > Furthermore, the S proposal is IMO generating more questions than
> > it strives to answer, and demands a non-trivial amount of further
> > work to fully understand its potential impact on the present use and
> > understanding of RDF.
> >
> > Given that the goal of the WG is to clarify the current 
> Recommendation,
> > including the typing of literals in terms of the current 
> Recommendation,
> > then the S proposal seems to me to go well beyond the constraints of
> > the charter, no matter how loosely one interprets it.
> 
> I suggest you re-read the charter, Patrick.
> 
> http://www.w3.org/2001/sw/RDFCoreWGCharter

I have. My apologies for paraphrasing my interpretation rather
than providing only quotations.

My proposal to drop the S approach is based on the following points 
of the charter:

"Backwards compatibility with existing RDF applications is a priority 
for the RDF Core Working Group."

tempered with 

"... it is the responsibility of this group to not let near-term 
deployment considerations grossly increase the future costs 
(to implementors, authors, users, etc.) of new features."

I presume that "applications" here does not mean only "software"
and that we should also be concerned about adopting changes which
may have ramifications that are not fully understood or which may
increase the burden of implementation over the long term (in other
words, let's be sure of what we add because we're likely to be
stuck with it for a long while).

I believe that we are generally in agreement that the S proposal is
not compatible to common usage, and therefore raises backwards
compatibility issues with existing content and systems based on
commonly used idioms.

But that is not my sole concern.

While we must consider the benefit of making some non-backwards
compatible changes which have clear and substantial benefit to future
applications, we must also consider the impact that changes and
extensions may have both to implementors as well as to content
producers. 

I do not see that the S approach is sufficiently superior
to the present idioms in use (P and DAML) for expressing the 
pairings of lexical forms (literals) to data type classes to 
justify the burden of reimplementation or conversion that
would be placed on present users, nor to justify the risk of
problems due to unknown issues deriving from such an approach.

I am very concerned that the full impact of the S approach
on both current and future applications, as well as on the common
understanding of RDF by users is *not* well understood, and recent 
discussions seem to be uncovering yet more issues with each day
rather than resolving them. These issues seem significant enough that
it is questionable whether they can be fully understood and addressed 
within a reasonable period of time and, as with other such unbounded 
issues, are better deferred for further exploration and discussion.

It also appears to me that the S proposal introduces a dichotomy
between typed literal resources and typed non-literal resources, which
has yet to be addressed and seems contrary to the fundamentals of
the RDF conceptual model.

Finally, I am of the view that the S proposal challenges several 
basic intuitions and assumptions about current RDF semantics and 
even if the affected semantics can be clarified, redefined, and/or 
extended, it will increase an already steep learning curve for 
wider adoption of RDF.

> [[
> The RDF Core WG is chartered to complete the work on RDF vocabulary
> description present in the RDF Schema Candidate Recommendation [..]
> RDF Schema must be expressed in terms of the RDF model, and 
> must use W3C
> RDF syntax. RDF Schema must use and build upon XML Schema 
> datatypes to the
> fullest extent that is practical and appropriate. [etc...]
> ]]
> 
> 
> Hmmm... haven't we been here before? Like 10 days ago?

No we haven't. You're comments 10 days ago were based on a
misunderstanding of what I was objecting to.

I've never had an issue with the charter or the support of
XML Schema data types.

> From 
> http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Nov/0325.html
> [[
> > > > I agree that RDF should use the XML Schema datatypes... i.e.
> > > > the value spaces and corresponding lexical representations.
> > >
> > > Please, NO!
> 
> > Now I'm confused. If you read and agreed with our WG's 
> charter before
> > joining RDF Core, this should come as no suprise.
> ]]

My objection in that post was to the adoption of XML Schema datatypes
as *primitives* of RDF, which was my understanding of the
suggestion being made at the time, and one that I was opposed to. 

I was not, nor have I ever been, opposed to the full support of 
XML Schema data types.

My interpretation of the charter is with the view that
whatever data typing solution is adopted and proposed by the 
WG it should not discriminate against or preclude the use of 
data typing schemes other than XML Schema. I am in full agreement 
that XML Schema simple types should be "first among equals", but 
not manditory or having treatment different from any other data 
type schemes.

I believe I am not alone in that view. I hope that such a
view represents a consensus of the WG.

All of my proposals and comments to this WG have been
made in the interest of full support for XML Schema data
types. In fact, I believe it is fair to say that I have
spoken as much or more than anyone else about the specific
qualities of XML Schema simple data types and how those
qualities could be addressed by whatever solution is adopted
by this WG.

> Could you please confirm that you have read the charter.

I have. I read it carefully long before I ever joined the
WG and read it again even more carefully when I joined the WG.

Your impression that I am not familiar with its contents or
purpose seems to be due to a misunderstanding on your part
of the meaning of my posts.

> There may be technical or deployment considerations that 
> count against S,
> but as far as I can see it is a reasonable fit with our charter.

While I do not assert that the charter completely rules it out, 
I am of the opinion that the sum total of the goals, priorities,
and considerations outlined in the charter weigh heavily against it.

Best Regards,

Patrick

 
> 
> >
> > Changes which are as significant as those proposed by the S proposal
> > should be deferred to a future (major) version of RDF.
> >
> > Therefore, I respectfully and humbly propose that the S proposal
> > be dropped from consideration.
> >
> > I further propose that a combination of the P proposal (not P++) and
> > a modified form of the DC proposal (changing rdfs:label to 
> rdfs:value,
> > per the current DAML usage) be adopted, providing two 
> (already commonly
> > used) means of pairing data type and resource, by typed 
> anonymous node
> > and/or rdfs:range implication.
> >
> > I.e.:
> >
> >      SUBJ PRED _:OBJ .
> >      _:OBJ rdf:value "LIT" .
> >      _:OBJ rdf:type TYPE .
> >
> > and/or
> >
> >      SUBJ PRED "LIT" .
> >      PRED rdfs:range TYPE .
> >
> > Which both define the pairing ("LIT",TYPE) which uniquely denotes
> > a value in the value space of TYPE.
> >
> >
> > Regards,
> >
> > Patrick
> >
> > --
> >
> > Patrick Stickler              Phone: +358 50 483 9453
> > Senior Research Scientist     Fax:   +358 7180 35409
> > Nokia Research Center         Email: patrick.stickler@nokia.com
> >
> >
> >
> > --
> >
> > Patrick Stickler              Phone: +358 50 483 9453
> > Senior Research Scientist     Fax:   +358 7180 35409
> > Nokia Research Center         Email: patrick.stickler@nokia.com
> >
>

Received on Thursday, 22 November 2001 06:30:08 UTC