Re: DATATYPING: second draft

At 10:19 14/12/2001 -0800, Sergey Melnik wrote:
[...]


>Correction: the interpretation of both nodes is the *same* literal value
>(which may be an element of both the lexical space of xsd:integer and
>the lexical space of xsd:string). I believe that S-B is equivalent to
>PL.

OK.  thanks for clearing that up.


>Assuming monotonicity, it does not matter whether you first do
>inferencing and then merge (and do inferencing again), or first merge
>all the data and then do inferencing on it. So, after merging we get:
>
>     <foo> <prop> _:"10" .
>     <foo> <prop> _:"10" .
>     <prop> <rdfs:rangeLex> <xsd:string.lex>
>     <prop> <rdfs:rangeLex> <xsd:int.lex>
>
>where _ is treated in a bNode-like fashion, so we still have two
>distinct triples. Then, according the rules you suggested, we can derive
>
>    <foo> <prop> xsd:string:"10" .
>    <foo> <prop> xsd:int:"10" .
>
>which is fine. However, we also derive
>
>    <prop> <rdfs:range> <xsd:int.val> .
>    <prop> <rdfs:range> <xsd:string.val> .

Yup - that would be bad news.  But I wasn't envisioning including the 
ranges statements in this scenario.  Just merging the range statements 
gives an empty range whatever we do with anything else.
[...]

>So far, this still looks fine given the desired result you wanted to
>obtain above. However, this is not much different from the S-B approach.

That was the idea.  I was wondering if it was possible synthesise the 
various approaches.


>There you start with
>
><foo> <prop> "10"
><foo> <rdfs:range> <xsd:int.val>
>
>and
>
><foo> <prop> "10"
><foo> <rdfs:range> <xsd:string.val>
>
>After merging, you get
>
><foo> <prop> "10"
><foo> <rdfs:range> <xsd:int.val>
><foo> <rdfs:range> <xsd:string.val>
>
>Here, the literal "10" is interpreted, as before, as some literal value
>that is both element of lex space of int and lex space of string. The
>schema information gives a hint that both lex spaces are to be
>considered by the application...
>
> > No matter, completing the job:
> >
> > Merging
> >
> >    <foo> <prop> _:"10" .
> >    <prop> <rdfs:rangeLex> <xsd:integer>
> >
> > and
> >
> >    <foo> <prop> _:"12" .
> >    <prop> <rdfs:rangeLex> <eg:oct>
> >
> > gives
> >
> >    <foo> <prop> xsd:integer:"10" .
> >
> > or
> >
> >    <foo> <prop> eg:oct:"10" .
> >
> > to a processor that 'understands' the xsd:integer and eg:oct datatypes.
>
>This is not all, though. From the merged data
>
>     <foo> <prop> _:"10" .
>     <prop> <rdfs:rangeLex> <xsd:integer.lex>
>     <foo> <prop> _:"12" .
>     <prop> <rdfs:rangeLex> <eg:oct.lex>
>
>you'd infer all of
>
>      <foo> <prop> xsd:integer:"10" .
>      <foo> <prop> xsd:integer:"12" .
>      <foo> <prop> eg:oct:"12" .
>      <foo> <prop> eg:oct:"10" .
>
>which includes integers 8, 10, and 12, and is not what you want...

Just so; the thing that breaks it is the merging of the rangeLex's though, 
not the representing a literal as a pair.

Brian

Received on Thursday, 20 December 2001 11:54:07 UTC