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

Pat Hayes wrote:
>
> >  > -----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.

Thanks for the candy ;) 

> >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??)

It's hard say just "yes" or "no". I would regard the "locally typed"
variant, of course, the best. In this case, the age of X is expressed
using

X --s:age--> D --s:inYears--> Y --s:inDecimal--> "12"

Given that the semantics of s:age is that D must denote a duration,
writing

X --s:age--> "12"

does not make any sense in S option. Hence, Pat, you are right - there
is only one option.

However, here is a different spin (inspired by Grahams CC/PP examples).
Most certainly we'll find triples like

X --my:age--> "12"

(notice a different namespace - s:age and my:age are two different
properties!)

In S, the literal "12" denotes a string. Thus, my:age denotes a
relationship between persons and strings, not between persons and
durations. However, the property my:age can be viewed as a "shortcut"
for

X --s:age--> D --s:inYears--> Y --s:inDecimal--> "12"
|                                                  ^
+----------------------my:age----------------------+

which may determine the duration D unambigously, or may not.

my:age looks like some kind of "non-local" typing. However, I'm not sure
Patrick had the same understanding when he was referring to it as the
one I have in mind. The key point is that s:age and my:age are two
distinct properties with different ranges and different semantics... In
particular, using my:age has little to do with datatyping, since "12"
still denotes just a string. No type is assigned to "12" by using the
property my:age. The only immediate conclusion we can draw from (X
my:age "12") is that the interpretation of X is restricted in some way.

> >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

Pat, thank you for such an insightful (and, I must admit, unexpected)
defense of the S proposal ;)

Sergey

Received on Thursday, 15 November 2001 20:04:22 UTC