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
>
>