- From: Sergey Melnik <melnik@db.stanford.edu>
- Date: Thu, 15 Nov 2001 17:31:38 -0800
- To: Pat Hayes <phayes@ai.uwf.edu>
- CC: Patrick.Stickler@nokia.com, w3c-rdfcore-wg@w3.org
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