- From: Phil Archer <parcher@icra.org>
- Date: Fri, 11 Jan 2008 11:44:04 +0000
- To: Jeremy Carroll <jjc@hpl.hp.com>
- CC: "Web Ontology Language ((OWL)) Working Group WG" <public-owl-wg@w3.org>, public-powderwg@w3.org
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:19 UTC