- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Sat, 16 Feb 2002 21:21:56 +0200
- To: ext Sergey Melnik <melnik@db.stanford.edu>, Pat Hayes <phayes@ai.uwf.edu>, Dan Connolly <connolly@w3.org>
- CC: RDF Core <w3c-rdfcore-wg@w3.org>, Dan Brickley <danbri@w3.org>
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