Re: Datatypes: unhappy of Bristol

>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