Re: Reopening tidy/untidy decision

Sergey--

I'd like to see some further discussion of points (a) and (3) you're 
making here, since I think that, while they are key points, I don't feel 
that they are entirely "substantiated" (at least not yet to my 
satisfaction), and I'd like some more details.  So adding this stuff to 
the document is great.

I don't feel the same about point (b) because I agree with it, but I 
don't think it matters that much.  I don't think anyone has claimed 
that, via specifying a datatype like integer for a value, you are going 
to capture all the application semantics that are associated with the 
use of that value in a property, and hence automatically forbid things 
like comparing ages and shoe sizes.  If you want to go to additional 
lengths to further specify the types (like defining types for age and 
shoe size, as some people would do), you can further constrain the 
interpretations, but clearly most people draw the line somewhere.  Not 
to mention the fact that you might not want to preclude yourself from 
doing some data mining type of operation that you hadn't thought of when 
you designed the type system that involves comparing people's ages and 
shoe sizes [this gets into my point about wanting different comparison 
operators, which I'll not get into here].  It seems to me the point 
we're trying to address here is somewhat simpler:  we've now introduced 
a datatype facility into RDF, where literals can be typed in several 
ways.  The question is (unless I'm mistaken), how does *RDF* interpret 
those literals that haven't been explicitly assigned a datatype by one 
of these mechanisms?  Do we say they have an implicit datatype of some 
sort (or have a fixed interpretation in some other way), or do we say 
they are the lexical things we talk about in the datatype facility, but 
we don't know what type they are?  Either way, applications are going to 
associate additional semantics with the values they get from RDF, and 
RDF won't know anything about those semantics.

--Frank

Sergey Melnik wrote:

> 
> Brian McBride wrote:
> 
>>
>> At 22:21 26/09/2002 +0300, Patrick Stickler wrote:
>>
>>
>>> I ask that the proponents of string-based (tidy) semantics
>>> present their arguments to the WG in the same manner
>>> as the proponents of value-based (untidy) semantics were
>>> asked to do prior ro last Friday's vote.
>>
>>
>>
>> That seems sensible.  I suggest we collect all the reasons for and 
>> against each proposal into the rationale document we started this week.  
> 
> 
> 
> Brian,
> 
> how can "tidy" folks contribute to that document? I'd like the reasoning 
> of [1,2] to be included. The points substantiated in [1,2] are these:
> 
> a) Untidiness is not required for correct modeling, or forward/backward 
> compatibility.
> 
> b) Untidiness does not solve a general issue of using substitute 
> artifacts in property ranges (claimed by untidy folks). Examples are 
> using strings instead of names, names instead of persons, strings 
> instead of integers, integers instead of kilograms, kilograms instead of 
> masses, integers instead of masses, strings instead of masses. This is 
> common modeling practice and cannot possibly be forbidden, let alone by 
> using untidy literals.
> 
> 3) Untidiness requires changes in existing apps and APIs, whereas tidy 
> interpretation does not.
> 
> 
> Sergey
> 
> [1] http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Sep/0283.html
> [2] http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Sep/0297.html
> 


-- 
Frank Manola                   The MITRE Corporation
202 Burlington Road, MS A345   Bedford, MA 01730-1420
mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-875

Received on Friday, 27 September 2002 08:01:04 UTC