RE: Proposal to drop S from consideration

> Applications on top of RDF parsers that know about dc:date
> take the string and do date stuff with it. But not
> the RDF parser itself.

I was never talking about RDF parsers. I was referring entirely 
to applications well above the parser level, operating on the 
knowledge embodied in the graph.

To an RDF parser, yes, all literals are just strings. As I stated, 
I see the RDF literal is a syntactic mechanism to provide a means of 
expressing a lexical form that corresponds to a value in some value
space of some data type. If it were just a string, and does not
denote a value, then all these discussions about data typing seem 
pointless. 

Data typing is clearly not a parser issue. Parsers are just for
mapping serializations to the graph model. Data typing has
to do (IMO) with how the pairing of lexical form and data type
is defined and represented in the graph, and how those
representations are interpreted in terms of the values denoted
by those pairings.

> > 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.
> 
> I see that as a misunderstanding of RDF 1.0's expressive
> capabilities.

Then it would appear to be a fairly widespread "misunderstanding".

> > > 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.
> 
> But is it a change to the RDF language?

 
> > 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.
> 
> It does more than suggest; it says quite clearly that
> Bob is an integer; this is one of the many false
> statements one can make with RDF. Yes, the
> use of rdfs:subPropertyOf, rdfs:range, and rdfs:domain
> is most sensibly constrained to uses that are
> consistent with their semantics. But this in
> now way motivates re-defining them.

But if our goal is simply to define the pairing of lexical
form to data type (and I assert that that is our goal)
then an approach such as the S proposal -- in comparison
to other proposals -- appears to be more complicated, require
more re-definition and explanation, introduce risk for user 
misunderstanding and unintentional false statements, and doesn't 
line up with common "intuitions" and practice than other 
alternatives.

Why burden users with yet more complicated mechanisms when
simpler mechanisms do the job just as well or even better?
(this is a serious question, really)

Rather than arguing that "we can make the S proposal work" or
"users will have to know what their doing" (both of which are
technically true), can you please address the question of what 
does the S proposal offer us towards meeting the goal of defining 
pairings of lexical form and data type that the combined idioms
P+DAML (which reflect current usage *and* common understanding) do
not provide?

> > 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).
> 
> On the other hand, P/U/DAML requires re-deploying RDF 1.0,
> not just clarifying it.

??? I'm not sure what you mean by "re-deploying". 

Leaving U out of the discussion (as it really is just a 
kind of synonym for the DAML idiom, per se) how does adopting
common usage as "official" require any kind of re-deployment?

> I see S as a straightforward layer atop RDF 1.0.

I do not see it as straightforward, and with every iteration
of the discussions about S, new mechanisms seem to be introduced
to "hold it all together" and accomplish what is already done
now with existing idioms and the currently defined semantics
of present RDF and RDFS mechanisms.

Adoption of the S approach will make all current idioms obsolete
and will require conversion of all knowledge expressed in those
idioms as well as all applications which utilized those idioms.

Thus, the S proposal poses a far greater impact to current 
systems than the P/DAML approach, yet does not provide for
data typing any better, IMO. The S proposal is "heavier" and less
compatible. And I have yet to see what its "saving graces"
might be that would make that extra machinery and re-tooling
of content/systems worthwile and reasonable. Not to mention
justifying burdening users with an even more complex and 
"tricky" RDF than they already must contend with.

Cheers,

Patrick

--
               
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, 29 November 2001 05:32:38 UTC