- From: <Patrick.Stickler@nokia.com>
- Date: Mon, 17 Dec 2001 03:21:28 +0200
- To: Graham.Klyne@MIMEsweeper.com
- Cc: w3c-rdfcore-wg@w3.org
> -----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