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

IRI set tester

From: Phil Archer <parcher@icra.org>
Date: Mon, 14 Apr 2008 14:35:50 +0100
Message-ID: <48035DB6.5050106@icra.org>
To: Public POWDER <public-powderwg@w3.org>

Following the e-mail sent by Stasinos [1] I've been looking at his ideas 
  for expressing IRI constraints *only* as regular expressions in 
POWDER-S. So things like

<iriset>
   <includehosts>example.org example.com</includehosts>
</iriset>

Becomes

<owl:Class>
   <owl:Restriction>
     <owl:onProperty rdf:resource="wdr:includeregex"/>
 
<owl:hasValue>://(\w+.)?(example.org|example.com)(:([0-9]+))?\/</owl:hasValue>
   </owl:Restriction>
</owl:Class>

For this to work, we'd need to specify what amounts to template regular 
expressions into which values derived from the XML encoded DRs could be 
placed. I wasn't sure whether this was possible... so I tested it. And I 
believe it is.

The tool under development at [2] takes values for most of our IRI 
constrains and turns each into a regular expression against which the 
(canonicalised) input IRI can be matched. I'm sure I've made mistakes 
and there's more to do, especially on the canonicalisation side, but I 
wanted to at least prove the principle.

Importantly, it is always the full IRI that is matched against the reg 
ex 9although the reg ex changes for each IRI constraint).

The best thing I can suggest is - try it! Enter values for any of the 
IRI constraints, and a candidate IRI and see what you get. For the 
candidate to be a member of the set you'd need to see all green. A 
single red and it's out.

This would allow us to define a single RDF property of includeregex (and 
its negative opposite). Stasinos worked out the datatype for this in his 
e-mail. We'd write the semantic extension for this property.

As Stasinos says in his mail, using this for port matching is not really 
possible in this manner, so, OK, that will need a different semantic 
extension. <includeportranges /> is in the tool.

I have not yet put in the CIDR block stuff for IP ranges - that does 
look potentially messy from a code point of view, but from a semantic 
extension point of view, I think it should be easy enough (a case of 
easier said than done!)

That would mean we end up with 3 semantic extensions in the grouping doc:

1. Reg Ex applied to IRIs
2. Port number processing#
3. CIDR block processing

Plus one in the DR doc (Temporal validity  for validFrom & validUntil)


Try it out - please!

Phil.


[1]
http://lists.w3.org/Archives/Public/public-powderwg/2008Mar/0017.html
[2] http://www.icra.org/regularexpression/
Received on Monday, 14 April 2008 13:36:31 GMT

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