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

RE: IRI set tester

From: Smith, Kevin, VF-Group <Kevin.Smith@vodafone.com>
Date: Mon, 14 Apr 2008 15:42:13 +0200
Message-ID: <37AC1116121D3F43B9A67CB16E2E79FF226846@VF-MBX11.internal.vodafone.com>
To: "Phil Archer" <parcher@icra.org>, "Public POWDER" <public-powderwg@w3.org>

Hi Phil, Stasinos,

This should (hopefully) be straightforward in the XSLT - do we have
updated versions of the POWDER documents and their equivalent POWDER-S
so that I can change the XSLT and test it against them? 

Cheers
Kevin

-----Original Message-----
From: public-powderwg-request@w3.org
[mailto:public-powderwg-request@w3.org] On Behalf Of Phil Archer
Sent: 14 April 2008 14:36
To: Public POWDER
Subject: IRI set tester


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:has
Value>
   </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:43:08 GMT

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