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

Re: Semantics, Basic, OWL 2 and POWDER

From: Stasinos Konstantopoulos <konstant@iit.demokritos.gr>
Date: Wed, 14 May 2008 09:25:45 +0300
To: Andrea Perego <andrea.perego@uninsubria.it>
Cc: Public POWDER <public-powderwg@w3.org>
Message-ID: <20080514062545.GC5745@iit.demokritos.gr>

On Wed May 14 01:14:56 2008 Andrea Perego said:

> >So we have our POWDER documents that we're now getting very familiar 
> >with and that Andrea is tying down in the XML schema. They're all in the 
> >POWDER namespace of http://www.w3.org/2007/05/powder#.
> >
> >Let's now associate an XSLT with that root namespace that does what I've 
> >been thinking the processor should do and convert the string-based 
> >elements into regular expressions, retaining all the attribution and 
> >descriptor sets stuff untouched. i.e. only the <iriset /> elements are 
> >transformed by this XSLT.
> >
> >We now have a document that will be in a different namespace, let's say 
> >http://www.w3.org/2008/05/powder-basic# (the fact that it's taken us a 
> >year to get to this point is depressing and potentially confusing but 
> >this is only ever going to be processed by machines, if ever). That 
> >document would look _very_ similar to a POWDER doc. It's still XML but 
> >now we only have includeregexp and excluderegexp elements in the IRI set 
> >(includehosts has disappeared along the way) so just pick those up and 
> >match the candidate IRI against them. 
> 
> Well, this raises an issue. In the current XML schema, it is required 
> for <iriset /> element instances to include one and exactly one instance 
> of the <includehosts /> element---i.e., in an IRI set definition it is 
> required to put a constraint on the host component of candidate IRIs. 
> The purpose is to avoid IRI set definitions of the type "all the 
> resources having an IRI path starting with /foo are blue." Of course, we 
> can drop this constraint, but, supposing that we want to keep it, we 
> have the following problem:
> 
> The proposal for the POWDER-BASIC schema requires just includeregexp, 
> i.e., it does not require any constraint on the IRI host. This means 
> that, if a POWDER-BASIC document is obtained from a POWDER one, the 
> constraint on the IRI host is kept, since it is in the original POWDER 
> document. However, if anyone writes directly his/her own POWDER-BASIC 
> document, we cannot be sure that the constraint on the IRI host will be 
> kept.
> 
> So, we have two options:
> 
> 1. Drop the constraint on the IRI host: in such a case, this won't be 
> required by POWDER, and POWDER-BASIC will be as proposed.
> 
> 2. Keep the constraint: in such a case, the POWDER XML schema won't be 
> changed, but we have to put such constraint in the POWDER-BASIC XML 
> schema. I see here a possible option: the POWDER-BASIC XML schema 
> requires one and exactly one instance of <includehosts /> AND 
> <includeregexp /> in an <iriset />.

The whole point of POWDER-BASIC is that it knows nothing about
<includehosts />, so (2) is not possible.

(1) is possible, but unnecessary. We can keep the POWDER constraint, and
not worry about POWDER-BASIC (or, for that matter, POWDER-S) authors.

Implementors of POWDER-BASIC extensions will have to specify their own
constraints, depending on their domain and target audience.

So, I suggest:

3. Keep the constraint: in such a case, the POWDER XML schema won't be
changed. Futhermore, not all POWDER-BASE documents can be turned into
valid POWDER documents. This looks OK, there is no reason to guarantee
the convertibility in this direction.

> A last question. Do we really need two distinct XML schemas? Actually, 
> POWDER-BASIC is a simplified version of POWDER, and thus it can be 
> included as a possible variant in the POWDER XML schema. In other words, 
> we can have a single XML schema, with two distinct namespace URIs.

POWDER-BASIC has only in/excluderegexp. POWDER has a whole bunch of
grouping elements. Other than that, they are the same. So the 
POWDER-BASIC validation is the same as PODWER, after stripping the
includehosts, includepaths, etc elements, and removing any
"exactly one" or "at most one" constraints associated with these
elements.

> Moreover, I agree that it is not a requirement for the processor to 
> enforce the XSL transform rules. And I would add, it should not be in 
> charge of validating a POWDER doc against the XML schema either. The 
> only requirement for the processor is to return the description of a 
> resource upon submission of its IRI.
> 
> Said that, most programming languages currently provide built-in support 
> for XSLT engines and XML validators, so it would be pretty easy to 
> extend a POWDER processor with these features. Moreover, in order to be 
> evaluated, a POWDER document must be valid. So, an alternative option is 
> possible, namely: before being evaluated by the processor, a POWDER 
> document is validated and then transformed into the POWDER-BASIC format. 
> In such a case, a POWDER processor must understand only POWDER-BASIC.

This might be a useful suggestion to the implementors, but I don't think
it should be a requirement.

> About this issue, I think that it might be important to make clear which 
> are the possible processing steps when dealing with extensions. If I've 
> understood correctly what you've said, we have two possible processing 
> options:
> 
> 1. POWDER + extensions -> POWDER ( -> POWDER-BASIC [optional] )
> 
> 2. POWDER + extensions -------------> POWDER-BASIC

No, 2 is:

POWDER-BASIC + extensions -> POWDER-BASIC

> Provided that we support both, are there any reasons why a specific 
> extension should use the former or the latter? Some words on this might 
> be useful to make clear how extensions can be implemented.

An implementor might choose to base their implementation
on either POWDER or POWDER-BASIC, depending on whether they need
URL-specific grouping elements or not. So, the WAF extension will be
more sensibly be derived  from POWDER, and the ISAN one from POWDER-BASIC.

s
Received on Wednesday, 14 May 2008 06:26:28 GMT

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