Re: help with dated entailments ... (for POWDER)

Hi Jeremy,

Just a little input from me on the work you're doing on the OWL wiki 
(POWDER WG members, please take a look - Jeremy's working very hard to 
solve our problems and I know you'll be as grateful as I am).

I note that you don't like POWDER Lite and Full - they were just names I 
used in my summary of our meeting last month, I'm more than happy to 
change them (and we've not taken any resolution on names in the WG yet 
so it's all open). Would you prefer something more formal like POWDER-O 
and POWDER-S (Operational and Semantic respectively)? or to be less 
formal with... oh the possibilities for school boy giggles are endless 
(keg, paint, puff...)

As for date-handling, the extension looks fine but... I think we've made 
too much of validFrom in the spec. This is really an embargo date (we 
did consider using the PRISM vocab for this btw but in the end it didn't 
quite fit the semantics). The key 'start date' really is dcterms:issued. 
What we want to say (and I can see we need to make this a lot clearer) 
is "If there is a wdr:validFrom date, then it overrides any 
dcterms:issued date, if present." - I can hear the screams already. And, 
I think you've got your befores and afters mixed up so can I offer this:

If <ddd,f> is in IEXT(I(wdr:validFrom)) and f is before the current 
date, then
   ddd is date-invalid

else if <ddd,f> is in IEXT(I(dcterms:issued)) and f is before the 
current date, then
   ddd is date-invalid

If <ddd,u> is in IEXT(I(wdr:validUntil)) and u is after the current 
date, then

ddd is date-invalid.

Otherwise ddd is date-valid.

If there is no "else if" allowed in this type of construct then the WG 
can discuss whether validFrom is worth fighting for.

I guess that a similar construct can be used for the wdr:linkFrom 
property [1] which also makes a DR's validity conditional on an external 
fact. If a DR includes the wdr:linkFrom property then, again, it can be 
valid or invalid - actually applicable or not applicable - but not both, 
the external fact being whether or not the described resource r itself 
includes a link to the DR. So have I understood this right:

If <ddd,r> is in IEXT(I(wdr:linkFrom)) and r does not include a link to 
ddd, then
   ddd is not applicable

Otherwise ddd is applicable

This has a double negative which I know is dodgy but the desired effect 
is "if there's no wdr:linkFrom then it's valid whether there's a link 
from r to ddd or not."

As for packages. I know this is a pain. Back in November when we looked 
at an OWL-based solution with reification, we worked out examples where 
the excluded URIsets were explicit. To save going back to old e-mails 
let me try and set out a (real world) example.

The fosi.org website includes several pages that have links to sites 
that many people would regard as being inappropriate for children, see 
for example, [2]. Thus, from a child protection point of view, any page 
on fosi.org with a path that starts with /associates needs a different 
DR than the rest of the site (which children would just find boring but 
that's another matter!)

So a modified version of the package as set out at [3] would be

1  <wdr:Package rdf:ID="p1">
2    <wdr:aboutHosts>fosi.org</wdr:aboutHosts>
3    <wdr:hasDRs rdf:parseType="Collection">
4      <wdr:DR rdf:about="#DR1" />
5      <wdr:DR rdf:about="#DR2" />
6    </wdr:hasDRs>
7  </wdr:Package>

Where DR1 would say words to the effect of 'probably not child safe' and 
DR2 would say 'child safe'.

Operationally, you start with DR1 and see if your candidate resource is 
in its scope. If not, move onto DR2.

Can GRDDL magic take us from such an operational package to a semantic 
DR that includes

<wdr:hasScope>
     <wdr:URISet>
       <owl:intersectionOf rdf:parseType="Collection">
         <owl:Restriction>
           <owl:onProperty rdf:resource="&wdr;includeHosts" />
           <owl:hasValue>example.org</owl:hasValue>
         </owl:Restriction>
         <owl:Restriction>
           <owl:onProperty rdf:resource="&wdr;excludePathStartsWith" />
           <owl:hasValue>/associates</owl:hasValue>
         </owl:Restriction>
       </owl:intersectionOf>
     </wdr:URISet>
   </wdr:hasScope>


i.e. the URIset explicitly excludes the /associates section so that the 
processing order doesn't matter?

Can GRDDL work through the Collection and derive fully-defined URIsets 
like this do you think?

You might ask why we don't require all DRs to include fully-defined 
URIsets. And the answer is, I'm afraid, a practical one again. It needs 
to be possible to include the same link across the whole of a given Web 
site to a single URI from which the correct DR for that resource can be 
identified through processing. That way you can set up your page 
template to include the same link regardless of the page content (or 
even better do the "it may not be standardised but it works" method of 
using HTTP Link  Headers). A killer-weakness of PICS was that content 
providers were required to put different labels on different pages. Not 
good I'm afraid.

Phil.

[1] http://www.w3.org/TR/2007/WD-powder-dr-20070925/#noPattern
[2] http://www.fosi.org/associates2/
[3] http://www.w3.org/TR/2007/WD-powder-dr-20070925/#package-structure

Jeremy Carroll wrote:
> 
> 
> A short peice for review, particularly the last sentence:
> 
> http://www.w3.org/2007/OWL/wiki/POWDER#Validity_and_Dates
> 
> [[
> A description resource, ddd, a member of ICEXT(I(wdr:DR)) may be either 
> date-valid, or date-invalid (but not both), depending on the current 
> date (today!), as follows:
> 
>     * If <ddd,f> is in IEXT(I(wdr:validFrom)) and f is after the current 
> date, then
> 
> ddd is date-invalid.
> 
>     * If <ddd,u> is in IEXT(I(wdr:validUntil)) and u is before the 
> current date, then
> 
> ddd is date-invalid.
> 
>     * Otherwise ddd is date-valid.
> 
> Additional constraints apply to interpretations of date-valid 
> description resources, that do not apply to interpretations of 
> date-invalid description resources. This step is regarded as pragmatic, 
> lying on the border of the formal semantics.
> ]]
> 
> 
> (elsewhere I will specify the additional constraints, essentially a 
> subclass relationship)
> 
> Jeremy
> 
>

Received on Friday, 11 January 2008 11:44:21 UTC