Re: Exact ranges and using S-B

In general, I would prefer to see a solution that introduces
the minimal amount of new vocabulary, though obviously, if
we need the new vocabulary to say what we need to say, fine.

If we can make the union interpretation of rdfs:drange suggested in

http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Feb/0469.html

work, then wouldn't that be preferable? As that allows the inline
idiom to be used freely with or without datatyping and without any
conflict with the other idioms.

The only thing it doesn't allow one to do is restrict property
values to only the lexical space of the datatype (rdfs:drange
constrains them to the union of the value and lexical spaces).

If it actually is needed to constrain the range to the lexical
space alone, then I agree that a new vocabulary is needed,
but perhaps it would be more economical to introduce a new range
property rather than use the shared bNode method.

E.g. 

 rdfs:range     value space only
 rdfs:lrange    lexical space only
 rdfs:drange    union of value space and lexical space

Though, we should be sure we want/need such restrictions because
while the union treatment of rdfs:drange allows for no conflicts
anywhere with arbitrary syndication of RDF graphs, any property
with rdfs:drange or rdfs:range and rdfs:lrange for the same datatype
will conflict.

I.e.

   ppp rdfs:range ddd .
   ppp rdfs:drange ddd .

no conflict, but

   ppp rdfs:range ddd .
   ppp rdfs:lrange ddd .

conflict, and

   ppp rdfs:drange ddd .
   ppp rdfs:lrange ddd .

conflict.

Is the union treatment of rdfs:drange enough? Or do
we need an absolute restriction to the lexical space alone
such as a range property like rdfs:lrange would provide?

Patrick


On 2002-02-15 19:35, "ext Sergey Melnik" <melnik@db.stanford.edu> wrote:

> After the main telecon DanC raised the point of how S-B can still be
> used and how the lexical spaces of datatypes can be referred to.
> 
> Pat suggested that writing
> 
> xsd:date rdfs:range _:1
> dc:Date  rdfs:range _:1
> 
> could do the job of making the range of dc:Date to be the lexical space
> of xsd:date. I'm contesting this point and making a suggestion.
> 
> As currently defined by the MT, the first statement asserts that
> 
> image(IEXT(I(xsd:date))) is subset of CEXT(I(_:1))
> 
> That is, CEXT(I(_:1)) may contain many other things besides the lexical
> tokens for dates. What we would need, however, is
> 
> CEXT(I(_:1)) is subset of image(IEXT(I(xsd:date)))
> 
> i.e. a tighter restriction on the interpretation of _:1.
> 
> Of course, we could define a new property like rdfs:restrictsByImage
> that has this effect. However, I think the most elegant way of handling
> this issue would be to introduce properties like rdfs:exactRange and
> rdfs:exactDomain with the "equals" semantics. For example, the
> interpretation for
> 
> xsd:date rdfs:exactRange _:1
> 
> would be
> 
> image(IEXT(I(xsd:date))) = CEXT(I(_:1))
> 
> In fact, these two properties are more powerful than rdfs:range and
> rdfs:domain or rdfs:restrictByImage altogether. For example,
> 
> my:prop rdfs:exactRange _:1
> _:1 rdfs:subClassOf my:Vehicle
> _:1 rdfs:subClassOf my:Boat
> 
> achieves the same effect as
> 
> my:prop rdfs:range my:Vehicle
> my:prop rdfs:range my:Boat
> 
> 
> I believe this is could be an issue for the schema subgroup (DanB?) to
> think about...
> 
> Sergey
> 
> 

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Saturday, 16 February 2002 14:20:30 UTC