- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Tue, 15 Jan 2002 17:32:42 +0200
- To: ext Graham Klyne <Graham.Klyne@MIMEsweeper.com>
- CC: Jeremy Carroll <jjc@hplb.hpl.hp.com>, RDF Core <w3c-rdfcore-wg@w3.org>
On 2002-01-15 17:02, "Patrick Stickler" <patrick.stickler@nokia.com> wrote: > On 2002-01-15 14:38, "ext Graham Klyne" <Graham.Klyne@MIMEsweeper.com> wrote: > >> At 09:45 AM 1/15/02 +0200, Patrick Stickler wrote: >> >>> The semantics of the rdfs:range 'constraint' (as I see it) is to >>> define an implicit union of data types, the members being the objects >>> of the rdfs:range, which may be used to >> >> "intersection", not "union" (per WG resolution). > > ??? I understood that 'union' meant the intersection of > lexical and value spaces. > > What's the difference? Ahhh, OK, I think I see where your coming from. A Union Datatype expects that its members are a member of at least one, but not all, of its subtypes. But the rdfs:range constraint defines an intersection of types (not union) such that a lexical form (property value) is considered (or required) to be a member of every specified type -- and of course, any of those types can be a Union Datatype. Thus, I can define a Union Datatype 'myUnion' with xsd:date and xsd:duration, which have totally disjunct lexical spaces, and I can then say ex:someProp rdfs:range xsd:string . ex:someProp rdfs:range #myUnion . which will never result in a contradition since xsd:string subsumes the lexical space of all lexical datatypes. Yet if I say ex:someProp rdfs:range xsd:date . ex:someProp rdfs:range xsd:duration . then I am sure to get a contradition every time, regardless of whether the literal is a valid xsd:date or xsd:duration since all rdfs:range defined types are inferred/required. Right? If so, then I'm OK with your definition of the equality of (a), (b), and (c) with regards to interpretation. 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 Tuesday, 15 January 2002 10:32:02 UTC