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

Re: Semantics, Basic, OWL 2 and POWDER

From: Andrea Perego <andrea.perego@uninsubria.it>
Date: Wed, 14 May 2008 15:33:02 +0200
Message-ID: <482AEA0E.8060708@uninsubria.it>
To: Public POWDER <public-powderwg@w3.org>

Hi, Phil.

Yes, we haven't explicitly stated that includehosts is mandatory, but 
there has been a lot of discussion related to the specification of 
"safe" DRs, and the requirement concerning includehosts has been 
mentioned. This is why I've included it in the *provisional* XML schema.

Anyway, if everybody agrees that the only requirement is that <iriset /> 
is not empty, I can update the schema accordingly.

Andrea


parcher@icra.org wrote:
> 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:34:01 GMT

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