Re: New DRs

Thanks Stasinos, we need this OWL input! Comments inline below.

Stasinos Konstantopoulos wrote:
[snip]

> I believe you will agree that if OWL vocabulary is used, it should be
> used as prescribed by the OWL specification, rather than using the
> formalism under a different semantics.

It clearly shouldn't lead to mis-understandings, no, but if what we 
publish is not processable by OWL tools, that doesn't bother me.

  Although not shown in Andrea's
> example, I remember a strong POWDER desideratum of being able to express
> overridable defaults. Imagine augmenting the example above with the
> following, based one of Phil's examples:
> 
> <owl:Class rdf:ID="ResourceOnExampleDotOrgAssociates">
>   <rdfs:subclassOf>
>     <owl:intersectionOf>
>       <owl:Restriction>
>         <owl:onProperty rdf:resource="wdr:includeHost" />
>         <owl:hasValue>example.org</owl:hasValue>
>       </owl:Restriction>
>       <owl:Restriction>
>         <owl:onProperty rdf:resource="wdr:startsPath" />
>         <owl:hasValue>associates</owl:hasValue>
>       </owl:Restriction>
>     </owl:intersectionOf>
>   <rdfs:subclassOf>
> </owl:Class>
> 
> <owl:Class rdf:ID="ResourceUnSafeForChildren">
>   <rdfs:subclassOf>
>     <owl:Restriction>
>       <owl:onProperty rdf:resource="&icra;oz" />
>       <owl:hasValue>false</owl:hasValue>
>     </owl:Restriction>
>   <rdfs:subclassOf>
>   <rdfs:subclassOf>
>     <owl:Restriction>
>       <owl:onProperty rdf:resource="&icra;vz" />
>       <owl:hasValue>false</owl:hasValue>
>     </owl:Restriction>
>   <rdfs:subclassOf>
>   [... more stuff ...]
> </owl:Class>

But you missed out a critical detail that was in my example.

ResourceOnExampleDotOrgAssociates is explicitly disjoint with 
ResourceOnExampleDotOrgButNotInAssociates. We'd use owl:complementOf to 
specify that this other class has includeHost fosi.org and NOT path 
starts with associates. Thus there is no contradiction in the data. You 
still can't reason over the data because we're not using closed axioms 
and all that, but the data is consistent.

It's an implementation pain as it would be easier for DR creators to be 
able to specify exceptions to the 'everything on fosi.org' pattern 
without having to list the exceptions in the 'top level' class - but 
that's a manageable problem.

[snip]

> 
> On a related note, on Tue Nov 20 16:59:16 2007 Phil Archer said:
> 
>> We are looking at OWL only because it appears to do what we need -
>> which is to provide a method through which we can publish a definition
>> of, say, 'mobileOK' and a resource set and find out that the resource
>> set is mobileOK. Importantly, it allows us to publish data in a format
>> that won't be misunderstood by existing tools.
> 
> This bit I am not entirely persuaded about; OWL appearing to do what
> POWDER needs, that is. URI Group membership rules and attribution (in
> their current form) do not fit into OWL, and that only leaves us with
> the mapping between URI groups and descriptors.
> 
> This latter aspect fits into OWL, but not perfectly, as, at least
> according to the current use cases, OWL is too powerful for the simple
> needs of this particular mapping. 

Yes, it's more powerful than we need. We're simply using a limited 
subset of OWL constructs to get us round the sticky problem we have with 
RDF. Without OWL, we end up with what we have published already which 
would entail us publishing documents that said "don't put this through a 
regular RDF tool kit or you'll get the wrong answer." We avoid that 
using a bit of OWL but we'll probably end up saying "this is valid OWL 
but you won't get any useful data out of it unless you use a rule 
language or some other method to extract the data."


> POWDER still can choose to keep OWL as
> part of the powder schema, as long as it is clear to POWDER that there
> is a lot of expressivity left untapped. Furthermore, POWDER tools have
> to realize that they might encounter complex OWL constructs, and know
> how to deal with them.

True. 'Dealing with them' will probably mean ignoring them in a POWDER 
context. If what POWDER does becomes useful in an OWL context, OK (but I 
doubt that it will).

> 
>> The foaf:maker attribute is critical! Without it, POWDER isn't POWDER.
>>
>>> IF 3 or more authories say it is ChildSafe
>>> THEN it is ReallyChildSafe
>> That's a rule that an implementor might define and use but it's beyond
>> the scope of POWDER. What we're about it providing the data that can
>> be used in rules, whether written in a semantically-rich environment
>> or just a straightforward Boolean statement.
> 
> POWDER has to specify what kinds of constructs are supported and what
> aren't.  You shouldn't think of this as an implementation detail, this
> is a representation issue, determining the form that DR rules take.

???? This is where you lose me. The kind of constructs we have to 
support are pretty straightforward:

On date 1, and until date 2, ACME testing said that everything on 
example.org/mobile was mobileOK

On date 1, and until date 2, the content provider said that everything 
on example.org except example.org/foo was accessible. This is supported 
by ACME testing.

The most complicated use cases are things like "Web site A is 
pedagogically useful but culturally obnoxious" and "when I tag something 
as 'mythical animal' I actually mean 'cryptozoology.'

All we're actually using OWL for really is to create something of a 
firewall around some RDF so it doesn't get misinterpreted. That does not 
mean it must be processable by OWL tools.

> 
> Supporting or not axioms like this is going to delineate the
> boundaries of the expressivity required by the POWDER formalism.  The
> usual trade-off of simplicity vs. expressivity applies, so the more
> complex things the labelling authority can say, the more demanding is
> the formalism going to be on the child-protection expert writing the
> rules.
> 
>> Now, about the issue raised by Stasinos about DR representation.
>>
>> In theory, a DR can be specified by using any suitable (knowledge
>> representation) language. However, the purpose of POWDER is to provide
>> specifications explaining how they can be expressed by using Web
>> technologies. So, we have three options:
>> - using XML
>> - using RDF/OWL
>> - using a Semantic Web rule language
> 
> RDF/OWL is one particular RDF schema, but not the only one. POWDER can
> define another RDF schema, which is not OWL. As a matter of fact,
> given the various constraints in place, it seems that POWDER can only
> be some (not OWL) RDF schema.

That's an interesting concept. I can't quite see how we'd define a 
parallel RDFS but I see what you mean.

[snip]
> 
> RDF is a semantics for XML,

I can think of several people who might want to shoot you for saying 
that. :-)

  that of sets of predicate-subject-object
> triples. OWL is a semantics for RDF, that of dyadic first-order logic.
> In other words:
> (a) all valid RDF documents are also valid XML documents.

No. All valid RDF documents can be serialised in valid XML but N3, 
Turtle and labelled directed graphs are also valid RDF. There is a 
growing call to fix the XML serialisation of RDF but that doesn't entail 
changing RDF itself.

[snip]

>> In OWL 1.1 a name can be used as any or all of an individual, a class,
>> or a property. The computational problems that would arise if this
>> were treated as in RDF are avoided by ensuring that no aspect of the
>> use of the name as an individual has any effect on the meaning of the
>> name as a class.

That makes sense (now that I've read it 15 times) but I'd have to see 
how that actually helped us practically.

> 
> This is why I insisted on discussing what kinds of constructs foaf:maker
> properties will be allowed to participate in. 

Simple. foaf:maker is the property that links the claims being made to 
the person that made them. In the model Andrea and I have been 
discussing today, that means you just use foaf:maker on the important 
'subClassOf' triple. Andrea suggests it's important to know who defined 
the resource Set and the Description - I'm less concerned about that as 
long as you know who makes the sub class relationship. But foaf:maker 
can link from any class to foaf:Agent.

This only becomes complicated if you want the data to be processable by 
a DL reasoner - which, the more I learn about this stuff, the more I 
want to run away from it as fast as possible!

No one can say we haven't discussed this! Good. And, again, thank you 
Stasinos. Please be sure that I am arguing against being limited by the 
strictures of OWL or any other technology in solving the basic problem 
we're working on and not arguing with you so to speak.

Phil.

Received on Monday, 26 November 2007 14:35:58 UTC