From: <Patrick.Stickler@nokia.com>
Date: Mon, 17 Dec 2001 03:21:28 +0200
Message-ID: <A03E60B17132A84F9B4BB5EEDE57957B160B45@trebe006.NOE.Nokia.com>

```

> -----Original Message-----
> From: ext Graham Klyne [mailto:Graham.Klyne@MIMEsweeper.com]
> Sent: 12 December, 2001 23:12
> To: Stickler Patrick (NRC/Tampere)
> Cc: w3c-rdfcore-wg@w3.org
> Subject: Re: Question about S
>
>
> At 01:06 AM 12/13/01 +0200, Patrick.Stickler@nokia.com wrote:
>
> >OK, I alluded to a question that I've asked several
> >times about a characteristic of the S approach for
> >which I feel I haven't gotten a satisfactory answer.
> >I did get one very short comment from Pat, which merely
> >emphasized my point (and concern).
> >
> >Here is the question again with examples:
> >
> >The S examples include statements such as the following:
> >
> >    Bob ex:age _:1 .
> >    _:1 s:integer "10" .
> >    s:integer rdfs:domain xsd:integer .
> >
> >I understand this to mean that the node '_:1' denotes a value
> >of type xsd:integer and there is a mapping to that value from
> >the lexical form "10" which is presumed to be a member of the
> >lexical space of xsd:integer.
>
> The statements above, as given, don't express the idea that "10" is a
> member of the lexical
> domain of xsd:integer.  Hence...

Then can you provide an alternate example that does? I'm
presuming that somehow, somewhere, we need to know that "10"
is a member of the lexical space of xsd:integer. How is that
defined in S if not as above?

> >However, this is extending the semantics of rdfs:domain in
> >a way that only apples to data type properties by saying
> >something about the object of the statement rather than
> >the class of the subject -- i.e. that "10" is a member of the
> >lexical space of xsd:integer.
>
> There's no extension to the semantics of rdfs:domain.
>
> The "special treatment" of datatypes is that the
> datatype-defining URIs
> have fixed interpretations. In the your example, having the
> definition of
> s:integer fixed so that its relational extension contains
> pairs of the form:
>
>      <1,"1">
>      <2,"2">
>      etc.

And then how do you declare a given URI as a datatype-defining
URI?

Perhaps you (or someone) could try (for my benefit, seemingly
having a rather challenged perspective) to give one or two
examples of how a pairing ("10", xsd:integer) is defined in
terms of the S 'idiom'?

It seems that every time I think I have a handle on the S
proposal, it appears I don't. Or maybe I do, iteratively,
but it seems to keep changing insofar as which mechanisms
are used to do what.

Leading off from Frank's list of basic requirements, and
taking the conceptual view of "doing" data typing by
capturing the pairing of lexical form and data type, how
does one, using the S idioms (of whichever flavor):

1. define the pairing ("10", xsd:integer) locally, with
explicit arcs on the object node; i.e. the equivalent
of the DAML idiom:

xxx ex:prop _:1 .
_:1 rdf:value "10" .
_:1 rdf:type xsd:integer .

2. define the pairing ("10", xsd:integer) globally, with
typing defined in a schema; i.e. the equivalent of the P
idiom:

xxx ex:prop "10" .
ex:prop rdfs:range xsd:integer .

[I see the P++ and U idioms to be synonymously equivalent
"contractions" of the DAML local typing idiom, so I won't
bother with them here]

As for S, I tried once to capture the various proposals/idioms using
this single example, including S, but it seems that I've never
quite gotten S nailed down.

Perhaps someone else can.

My earlier (apparently flawed) understanding had me doing S local
typing with something like the following (based on the earliest
S examples)

xxx ex:prop _:1 .
_:1 xsd:integer "10" .

which had me wondering why one couldn't also do S global typing
with

xxx ex:prop "10" .
ex:prop rdfs:subPropertyOf xsd:integer .

but then folks started bringing rdfs:domain into play, to
avoid the need for xsd:integer itself to be a property, and
sets of different URIs for the lexical and value spaces, etc.
and things just got a bit too muddy for me...

Examples would be much appreciated to help clarify how S serves
to define such pairings (presuming it does/can/cares to).

Cheers,

Patrick

--

Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com
```
Received on Sunday, 16 December 2001 20:21:31 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:54 UTC