RE: Answer to the question: What is a "value" to RDF

>  > -----Original Message-----
>>  From: ext Pat Hayes [mailto:phayes@ai.uwf.edu]
>>  Sent: 15 November, 2001 03:41
>>  To: Stickler Patrick (NRC/Tampere)
>>  Cc: w3c-rdfcore-wg@w3.org
>>  Subject: RE: Answer to the question: What is a "value" to RDF
>>
>>
>>  >  > > Well hold on. It isn't clear that there are any RDF classes
>>  >>  denoting
>>  >>  > datatypes, at present. In the S proposal, for example,
>>  >>  datatype names
>>  >>  > are RDF property names, not class names. So I do not
>>  know from what
>>  >>  > population you are getting 'most' here.
>>  >>
>>  >>  Right. I stand corrected. I should have stated "Most RDF resources
>>  >>  denoting..."
>>  >
>>  >Actually, I take that back.
>>  >
>>  >rdfs:range expects a class as its value, and I think it is
>>  >a fairly reasonable assumption that data types are classes,
>>  >per the semantics of subClassOf, etc. so even though it might
>>  >not be strictly stated somewhere that data types are RDF classes,
>>  >I think it is fair to assume they are, and perhaps it should
>>  >be stated as such.
>>
>>  Well, the S proposal would have them be properties. And I have to
>>  admit, even though my name is on a different proposal, that this idea
>>  of datatypes as properties does rather better capture the intuition
>>  that the core notion in datatyping is a *mapping* from a lexical to a
>>  value space.
>
>Firstly, it only pairs the literal lexical form with the data
>type, it doesn't define a mapping of the lexical form to the
>value space of the data type.

It doesn't DEFINE it, but it does identify it.

>To do that, it would have to
>identify the value being mapped to. All it does in infer that
>such a mapping exists.

No, the mapping is named right there in the triple, eg 'xsd:integer'.

>
>Secondly, it does not allow one to centralize data type knowledge
>by means of rdfs:range.

True. But as you have pointed out, that brings its own dangers. And 
note that one can use sub-property reasoning, eg:

aaa eg:prop _:x .
_:x foodle "23" .
foodle rdfs:subPropertyOf xsd:integer .

would work, and could be used to provide some 'centralization', perhaps.

>Thirdly, it introduces two

One, to be fair.

>variant graph representations for
>locally typed or non-locally typed literal objects whereby
>in the first case, a proxy bNode is inserted in between
>the predicate arc and the literal object while in the latter
>case the predicate arc terminates in the literal object itself.

As I understand the S option, that latter form would not be used 
(except for cases like xsd:string, maybe, where the value space is 
isomorphic to the lexical space)

(Sergey, is that right??)

>Honestly, I find that the S proposal bends (and breaks) just
>too many established intuitions and expectations about RDF
>semantics,

I don't think it breaks the semantics at all; it just insists on a 
rather rigorous way of understanding the meaning of literal labels. 
That may ruffle many expectations, I concede. But part of our task 
may be educational :-).

>and despite being clever or making some parts of the
>MT easier to define, I don't see it as making life any easier
>for implementors, but actually see it as making life harder
>for implementors (and knowledge producers)

Actually I think there is a tradeoff here. The S and U proposals will 
be harder on K. producers, since they require them to use a 
particular syntax and insist that certain idioms be used. But they 
will be easier on implementors, since inference will be simpler to 
check and all applications can know exactly where to look for certain 
kinds of information.

This is the classical tradeoff between inferential simplicity and 
expressiveness, in fact, illustrated in miniature.

>because it introduces
>variations in the graph structures for (implied) statements
>and makes global range defined types impossible (or at best
>difficult) to define, precluding contextualized type
>associations defined by schema.
>
>Let's not lose sight of the impact that a given proposal
>will have to "the big picture" by focusing too much on what
>it offers to the MT alone.

The MT can handle any of the proposals, but the point is that with 
some of them (notably U and S) it would be greatly simplified. That 
simplification reflects a simplification in the language itself; it 
is 'cleaner' and easier to understand, easier to write inference 
engines for, easier to extend, and so on. The advantages are 
pragmatic rather than, er, philosophical .

Pat

-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Thursday, 15 November 2001 15:46:10 UTC