- From: Stasinos Konstantopoulos <konstant@iit.demokritos.gr>
- Date: Wed, 23 Apr 2008 14:20:16 +0300
- To: Phil Archer <parcher@icra.org>
- Cc: Public POWDER <public-powderwg@w3.org>
On Wed Apr 23 10:41:15 2008 Phil Archer said: >>>>> and which should we use? >>>> >>>> It's hard to tell in isolation, depends on where "resourceset_1" comes >>>> from. If it is defined as a restriction on a property, then these two >>>> might as well mean the same. >>> >>> Good. I much prefer the second option - i.e. the one that doesn't >>> mention hasIRI. The context is a GRDDLed DR so I think this is clear. >> >> well, there's no way around the hasIRI, it's lurking there somewhere in >> the definition of "resourceset_1". It just that it's not visible in this >> particular fragment. > > Yes, but hasIRI isn't actually used anywhere in the class. We define > hasIRI as a semantic extension linking strings to URIs but then we > gently ignore it and use regex for most things. Actually, if you succeed > in using regex for port numbers and CIDR blocks then we should probably > change the semantic extension to define wdr:regex directly. This is, of > course, the grey area - more semantic gloop actually - that we're in > here ... Well, yes, I totally agree that it better to hide the IRI-as-a-string extension under a "front-end" that does what POWDER needs and nought more. Which was ALT 2 in the "long email", which calls for the addition of an OWL vocab item hiding the hop from abstract instances to concrete IRI strings. The suggestion there was to add a quantifier over *resources* (not strings) which magically collects all resources the IRI of which is whithin an XML type. So, what will get hacked? underlying RDF semantics or OWL "front-end" vocabulary? s
Received on Wednesday, 23 April 2008 11:20:53 UTC