Re: Question about "cohabitation" of S idioms A and B

The implication that

    _:1 rdf:type xsd:integer.lex .
and
    _:1 rdf:type xsd:integer.val .

is only incorrect with respect to the intended interpretation of 
"xsd:integer.lex" and "xsd:integer.val".  The problem is that you made 
statements which were inconsistent with that intended interpretation (you 
used ex:age with different-type objects - one from the integer lexical 
space, and the other from the integer value space).  For RDF, it's 
perfectly legitimate RDFS-entailment, and might quite reasonably be 
consistent with some different intended interpretation.

In a different message to Brian, you said:
>The examples I used were based on those given in Sergey's definition
>of the A and B idioms. Perhaps there are errors there?

Unlike Sergey's similar example, you have used the *same* URI (ex:age) for 
each idiom.  Sergey's examples of A and B use 'exA:birthdate' and 
'exB:birthdate', so the problematic entailments do not arise.

#g
--

At 06:50 PM 1/10/02 +0200, Patrick Stickler wrote:

>Sorry if I appear to be in a "slam S" mood today (I'm not, really ;-)
>but...
>
>It appears to me that the S idioms A and B are not compatible
>for both local and global typing in the same knowledge base
>as are the P and D (and U) idioms.
>
>If I want to allow for both global and local typing, there
>arise problems. E.g. given the following, per idiom B
>
>    Bob ex:age "10" .
>    ex:age rdfs:range xsd:integer.lex .
>
>implies, as we desire, that the lexical node "10" is a member
>of the class xsd:integer.lex. Fine.
>
>Now we have, in addition to the above, per idiom A
>
>    Jenny ex:age _:1 .
>    _:1 xsd:integer.map "22" .
>    ex:age rdfs:range xsd:integer.val .
>
>which implies, as we desire
>
>    _:1 rdf:type xsd:integer.val .
>
>This also apparently could have been inferred from the statement
>
>    xsd:integer.map rdfs:domain xsd:integer.val .
>
>Again, Fine.
>
>But taking the first range statement into account along with
>the statements about Jenny, we also now have the implication
>
>    _:1 rdf:type xsd:integer.lex .
>
>which obviously is not correct.
>
>We also have the unintended (?) implication (though not representable
>without P+) that the literal node "10" in the statement about Bob is
>of type xsd:integer.val. In P+:
>
>    "10" rdf:type xsd:integer.val .
>
>Now, maybe it is, and maybe it isn't, but the S specification doesn't seem
>to allow a node to be both .lex and .val at the same time.
>
>What this boils down to is, if the A and B idioms of S trully are not
>compatible in the same knowledge base, then S does not appear to provide
>a means for both global and local typing in the same environment.
>
>Comments? Corrections?
>
>Am I missing something important here???
>
>--
>
>In comparison, if we define the above knowledge in the P and
>D (and U) idioms
>
>    Bob ex:age "10" .
>    ex:age rdfs:range xsd:integer .
>
>    Jenny ex:age _:1 .
>    _:1 rdf:value "22" .
>    _:1 rdf:type xsd:integer .
>
>    Fred ex:age <xsd:integer:47> .
>
>we have the desired implication about Bob's age
>
>    "10" rdf:type xsd:integer .
>
>(which of course can't really be represented a such without P+)
>
>along with (possibly unintended) implications about Jenny's and
>Fred's ages, knowledge which we already knew from local definitions,
>but nevertheless can be (or may be intended for) use to test for
>contraditions
>
>    _:1 rdf:type xsd:integer .
>    <xsd:integer:47> rdf:type xsd:integer .
>
>BUT *no* conflicts or undesirable interaction between any of the idioms.
>
>One additional point: the D idiom (and U) for local typing does not
>require *any* global schema information for intepretation, yet
>both the A and B idioms of S appear to require schema defined knowledge
>for interpretation (or then parsing and interpretation of URIrefs
>to look for .lex, .map, etc. suffixes and data type prefixes, etc.).
>
>--
>
>Thus S does not appear to provide a means of fully localized,
>schema free, definition of data types for literals, which I
>recall was one of the requirements.
>
>Examples to the contrary are very welcome.
>
>Cheers,
>
>Patrick
>
>--
>
>Patrick Stickler              Phone: +358 50 483 9453
>Senior Research Scientist     Fax:   +358 7180 35409
>Nokia Research Center         Email: patrick.stickler@nokia.com

------------------------------------------------------------
Graham Klyne                    MIMEsweeper Group
Strategic Research              <http://www.mimesweeper.com>
<Graham.Klyne@MIMEsweeper.com>
        __
       /\ \
      /  \ \
     / /\ \ \
    / / /\ \ \
   / / /__\_\ \
  / / /________\
  \/___________/

Received on Friday, 11 January 2002 11:29:15 UTC