Re: Semantics, Basic, OWL 2 and POWDER

A train near Frankfurt station is not ideal place to write this. If I had
more time I'd head for T-Online Allee and drop in for a Kaffe and Kuchen
with Kai but, alas, Nuremberg awaits. So let me chuck in a couple of minor
things while I meander along the River Main.

As far as I can recall, we have never said that includehosts is required.
We have said that an IRI set MUST NOT be empty, but I believe

<includeregex>.*</includeregex>

however unwise, is valid.

But, I have thought that we might want to make includehosts mandatory.
ICRA labels will certainly all include this element, Even so, I'm not
convinced that it's necessary. If it is not possible to use XML Schema
language to require at least one child element of <iriset /> then, OK,
maybe we need it. Maybe others can comment - this fence sitting is
becoming painful!

Secondly, I made a mistake in the origianl e-mail. As Stas says, a generic
POWDER Processor really only needs to understand POWDER-BASIC. However, I
propose that whilst that is the conformance criteria, we should also say
that unless the processor is closely tied to a specific extension that
only makes use of BASIC, a typical PP will also understand POWDER. In
other words, if you are setting up a PP as a front end to a database of
ISAN numbers, you don't need to implemenet includehosts, but if you're
using includehosts, a good processor will not necessarily need to go
through BASIC to handle it.

Phil.

>
> On Wed May 14 12:08:07 2008 Andrea Perego said:
>
>>>> 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.
>>
>> I was not proposing to keep the constraint on the IRI host with the
>> purpose of converting POWDER-BASIC into POWDER. The problem is, as I
>> said, that, if only includeregexp is required, I can write a
>> POWDER-BASIC document claiming that "all the resources hosted by any
>> host, and having a path starting with /foo, are blue." Should we allow
>> this?
>
> POWDER-BASIC knows nothing about hosts and paths, it only knows how to
> match IRIs against regexps. So, yes, POWDER-BASIC authors can write
> overly generic regexps like "http://[^/]+/foo" or even ".*" if they
> really want to.
>
> Note, however, that POWDER-BASIC is not meant for POWDER authors but for
> POWDER extension developers, who should know better than to define an
> extension that allows this to happen. See how POWDER requires
> includehosts, ISAN could, for example, require includeroots, and so on.
>
> s
>
>

Received on Wednesday, 14 May 2008 13:15:58 UTC