W3C home > Mailing lists > Public > public-powderwg@w3.org > December 2008

Re: Naïve question: Datatypes for RDF Properties?

From: Stasinos Konstantopoulos <konstant@iit.demokritos.gr>
Date: Tue, 9 Dec 2008 18:15:15 +0200
To: "Hammond, Tony" <t.hammond@nature.com>
Cc: Phil Archer <phil@philarcher.org>, public-powderwg@w3.org
Message-ID: <20081209161515.GA29176@iit.demokritos.gr>

Tony, hi.

On Tue Dec  9 15:27:24 2008 Hammond, Tony said:

> I understand that the limitation to authprity-based URIs ("//...") may be be
> predicated on pragmatics and appreciate you pointing out the POWDER-BASE
> workaround for generic regex'es. (It is a shame though that some URIs are
> treated as more equal than others but then that's just a pet gripe of mine.
> ;)

If I may same so, it would, indeed, be a shame if some URIs were treated
as more equal than others, but they are not. In fact, this WG has spent
a significant proportion of its total effort in making sure that there
is nothing specific to resolvable URLs lurking in POWDER's foundations.

The formal essence of the grouping-by-name mechanism is the BASE and
OWL/RDF formalisms. Application builders are free to define any
<in/exclude*> grouping restrictions they like, as long as they can be
translated into <in/excluderegegexp>. There is nothing special
whatsoever about <includehosts>, except that the WG bothered to define
it (again, NOT in POWDER-BASE but in POWDER/XML which is specifically
targeted at the web). Note how POWDER/XML is defined using POWDER-BASE
primitives making no special concession to better or more easilty
accommodate resolvable things. This has, by the way, cost us port ranges
since numeric comparisons are really hard to "emulate" with regexps, but
we didn't want to add any URL-specific portrange elements in -BASE.
Note also how in the grouping doc we use POWDER-BASE primitives to
define grouping elements for (non-resolvable) ISAN-number URIs.

This is, IMHO, one of the strongest aspects of POWDER: we expect that it
is mostly going to be used in web applications, but there is no
"increased equalness" whatsoever towards resolvable URIs.

Going back to the beginning of the thread, we anchor <includehosts>
restrictions on :// and keep other IRIs from matching. This is a
feature, and a good one IMO, not a bug. Would you *really* want
that <includehosts> restrictions can match a <urn:ISAN-number> IRI?
Do you have a use case in mind where one would need that?

Best,
s
Received on Tuesday, 9 December 2008 16:17:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:42:13 GMT