- From: Pat Hayes <phayes@ai.uwf.edu>
- Date: Sun, 24 Feb 2002 16:14:08 -0600
- To: "Jeremy Carroll" <jjc@hplb.hpl.hp.com>
- Cc: w3c-rdfcore-wg@w3.org
>Despite DanC's wanting people to accept votes that go against them, I feel >that part of the consensus process is for people who are deeply unhappy with >the way things are going to explain why. Then the rest of group can listen, >and hopefully take on board the issues. > >I can go along with the first three positions decided at the telecon ( S-B >style idiom, tidiness, no doublet) but I object very strongly to retaining >the triplet. We have to have SOME way to talk about the value of a literal under a datatype. Otherwise RDF is dead in the water, and Tim's layer cake has dry rot. > >I don't think the triplet fits at all with the S-B approach that the >majority of the group favour. > >The S-B style says that in the triple > <Jenny> <ageB> "10". >Jenny's age is a string (range constraints do not change this). >The triplet approach (aka S-A) permits us to say something like: > ><Tommy> <ageA> _:b . >_:b <integer> "10" . > >and Tommy's age is the integer 10. > >Whatever we do to the range constraints, or however clever we are with the >age properti(es) I do not believe we can get the entailment: > ><Jenny> <age> _:x . ><Tommy> <age> _:x . > >i.e. that Jenny and Tommy have the same age. They don't: one has an age >which is an integer, the other has an age which is a string; but both have >been alive the same length of time! Well, yes. but is this a bug or a feature? Sure they have been around the same number of years, but we are using two different 'age' properties here. The librarians are talking about Jenny and the IRS are talking about Tommy, and they have different schemas for stating things about ages. This kind of thing is bound to happen, it happens all the time; we aren't going to be able to legislate it out of existence. But we can do this. Jenny has an ageA and Tommy has an ageB, and they both have an ageU, and ageA rdfs:subProperty ageU . ageB rdfs:subProperty ageU . and now you can assert ageU properties using numerals OR numbers. And we can say things like Jenny ageU _:x . Tommy ageU _:y . _:y xsd:number _:x . to make the connections, if we want to get into details. Would that be good enough? Seems to me that this kind of thing is what rdfs:subPropertyOf was designed for. >[I am being deliberately vague about the exact property names, maybe they >are all the same]. They had better not be :-) >I can live with the S-B idiom and semantics. I really like the S-A idiom and >semantics. But they don't fit together. Providing two incompatible means to >say the same sort of thing seems to me to be the very worst of design by >committee. But what is wrong with allowing people to express things in several different ways? Some people WANT to talk about strings, and some people WANT to talk about numbers. RDF should be able to accommodate them both. Its not our job to impose a particular ontology on users, only to give them the tools to express what they want to say. Obviously if they use the same name to do both with at the same time, then things will get a bit confused; but that's to be expected, like I said. People have to be careful, when using names that come with schema constraints, to follow those constraints in order to avoid confusion: fact of life, right? >If we are so committed to the S-B idiom and tidyness then in my view we >should drop the desire to have a local datatyping idiom, because we have not >found a local datatyping idiom that is compatible with S-B and tidyness. > >I think Pat's simpledatatypes2 is magic and I regret that we have not been >allowed to consider it. > >Jeremy > > >More for the diehards ... >========================= > >We have talked about the line between the application datatyping and the >datatyping within RDF. In S-A and S-B this line is drawn at a very different >place, and I believe that if we choose both then this will be an ongoing and >festering sore of confusion. Id rather say that it provides the ability to be on either side of the line. We can give advice to users on how to stay firmly on one or the other side, of course, if that is what they want to do. >If we are going to limit datatyping to checking that strings are in lexical >spaces, let's do that. If we are going to use datatyping to deliver typed >values, let's do that. But trying to do both to please two different >constituencies within the WG is a mistake. Hmmm, but if we are going to make RDF be of general utility, rejecting the second option is a non-starter, seems to me. Which means we have to be willing to say, to hell with Dublin core and CC/PP. (Fine with me, butI predict blood in the streets if we try it... :-) >From a process point I prefer us considering coherent proposals as whole >items, rather than having a shopping list of features so that the final >requirements may or may not be satisfiable. I agree as a point of process. BUt regarding S-A and S-B, I think they are *satisfiable*, but having both does mean that users have to think about which way they want to set the switches. But Im sure we can write a user guide that will make it reasonably clear. I think that the WG right now has a sense of dizzyness because of the process we have gone through. Once the dust settles it will look better. 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 Sunday, 24 February 2002 17:14:12 UTC