Re: test case A revisited

BTW, I consider this example to very strongly demonstrate why
we should have RDF datatyping operate in sync with the semantics
of rdf:type and rdfs:range -- because the approach outlined
below for typing of container members is not specific to
datatyping -- even though the examples all use datatyped
literals -- but relates to the general typing of container members,
regardless whether they are literals, blank nodes or URIrefs.

Everything simply falls out of the fact that datatyping of
literals is built upon rdfs:range and rdf:type semantics
(which require untidy literal semantics).

If we had some other mechanisms, such as rdfd:dcv etc. then
in every such case as this, we'd have to continually provide
*two* solutions, one for datatyped values and one for all
other kinds of values. Blech! (and that's putting it mildly ;-)

Even if we don't adopt any kind of rdfs:memberRange mechanism
now, it still demonstrates the economy and compatability of the
untidy/rdfs:range/rdf:type approach with such solutions in the
future, such as those anticipated with RDF 2.0.

Cheers,

Patrick



On 2002-07-02 10:11, "ext Patrick Stickler" <patrick.stickler@nokia.com>
wrote:

> 
> On 2002-07-01 20:37, "ext Brian McBride" <bwm@hplb.hpl.hp.com> wrote:
> 
> 
>>> + containers cannot contain globally typed literals (i.e. the literals are
>>> either self-denoting or untyped)
>> 
>> Hmm, the question is which.  The later seems to imply, if one puts a
>> literal in a container, then one doesn't know what it denotes.
> 
> What is needed, and has been needed for a long time, is a new
> range property for containers. E.g.
> 
>  rdfs:memberRange a rdf:Property ;
>     rdfs:domain rdfs:Container ;
>     rdfs:comment "Used to indicate the class(es) that
>                   the members of an instance of the
>                   container class will be members of." .
> 
> where the following closure rule apply
> 
> IF
>  ?x a rdfs:Container .
>  ?x a ?c .
>  ?c rdfs:memberRange ?r .
>  ?x rdfs:member ?m .
> THEN
>  ?m rdf:type ?r .
> 
> 
> So, if we had some container type 'foo:WidgetScores':
> 
>  foo:WidgetScores rdfs:subClassOf rdf:Bag .
>  foo:WidgetScores rdfs:memberRange xsd:integer .
> 
> then given an instance of foo:WidgetScores:
> 
>  _:i a foo:WidgetScores ;
>     rdf:_1 "10" ;
>     rdf:_2 "9288" ;
>     rdf:_3 "821" ;
>     rdf:_4 "4" ;
> 
> which, given the above closure rule for rdfs:memberRange
> semantics, means that each of the literal node members
> of the collection denote integer values.
> 
> The datatyping is not associated with the property, but
> with the collection.
> 
> Of course, the above presumes (a) untidy literal semantics
> and (b) literals (at least implicitly) as subjects.
> 
> I.e. it equates to the following interpretation:
> 
>  _:i a foo:WidgetScores ;
>     rdf:_1 _:a"10" ;
>     rdf:_2 _:b"9288" ;
>     rdf:_3 _:c"821" ;
>     rdf:_4 _:d"4" ;
>  _:a"10" rdf:type xsd:integer .
>  _:b"9288" rdf:type xsd:integer .
>  _:c"821" rdf:type xsd:integer .
>  _:d"4" rdf:type xsd:integer .
> 
> And of course, the memberRange need not be a datatype. It
> can be any RDF class whatsoever.
> 
> And also, we need not introduce literals as subjects at
> this time in order to adopt such an approach as above. The
> rdf:type'ing can simply be left implicit in the interpretation.
> But, if/when literals can be subjects, it all fits right
> in perfectly with untidy literals and rdfs:range based datatyping.
> 
> 
> Patrick
> 
> --
>              
> Patrick Stickler              Phone: +358 50 483 9453
> Senior Research Scientist     Fax:   +358 7180 35409
> Nokia Research Center         Email: patrick.stickler@nokia.com
> 
> 
> 

--
               
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, 2 July 2002 04:12:40 UTC