Re: URI groups

What I _think_ Stasinos is saying is that 1 looks is if it defines the 
class fully - but it doesn't. 2 very definitely doesn't define the 
class. Neither is a full definition so that at best it is pointless and 
at worst misleading to use the more complex construct.

If this understanding is correct, then it means our DRs can be much 
shorter, even when we're doing something relatively complicated like this:

1  <owl:Class rdf:ID="FOSIassociates">
2    <wdr:includeHost>fosi.org</wdr:includeHost>
3    <wdr:pathStartsWith>associates</wdr:pathStartsWith>
4    <owl:disjointWith rdf:resource="#FOSI" />
5    <rdfs:subClassOf rdf:resource="#NotChildSafe"
                             rdf:ID="assertion1" />
6  </owl:Class>

7  <owl:Class rdf:ID="FOSI">
8    <wdr:includeHost>fosi.org</wdr:includeHost>
9    <wdr:pathNotStartsWith>associates</wdr:pathNotStartsWith>
10   <owl:disjointWith rdf:resource="#FOSIassociates" />
11   <rdfs:subClassOf rdf:resource="#ChildSafe"
                          rdf:ID="assertion2" />
12 </owl:Class>

13 <owl:Class rdf:ID="ChildSafe">
14   <icra:allZ>true</icra:allZ>
15 </owl:Class>

16 <owl:Class rdf:ID="NotChildSafe">
17   <icra:allZ>false</icra:allZ>
18 </owl:Class>

19 <rdf:Description rdf:about="#assertion1">
20   <foaf:maker rdf:resource="http://example.org/people.rdf#david" />
21   <dcterms:issued>2007-12-10</dcterms:issued>
22   <wdr:validUntil>2008-01-01</wdr:validUntil>
23 </rdf:Description>

24 <rdf:Description rdf:about="#assertion2">
25   <foaf:maker rdf:resource="http://example.org/people.rdf#david" />
26   <dcterms:issued>2007-12-10</dcterms:issued>
27   <wdr:validUntil>2008-01-01</wdr:validUntil>
28 </rdf:Description>

I've included the sub class assertions directly in the classes just to 
show that it can be done. Also, doing it this way, we _retain_ the 
negative versions of our grouping properties and the white space 
separated lists. I don't think that this latter point will go down well 
with the SW purists.

I believe that we'll end up with the more sophisticated construct, using 
owl:equivalentClass but time will tell.

The point Stasinos makes about it not being clear that a host of y.z 
includes x.y.z is true, of course, but it's also true that no string has 
any meaning as an inherent property, surely?

I think the data will be extracted from these things using SPARQL which 
has built-in support for regular expressions - so covering x.y.z by 
declaring y.z doesn't look so hard.

And for the record - it's not that there is no W3C Recommended Rules 
language that makes me averse to a rule-based definition of DRs it's that:

1. DRs are there to say that a Web site, or collection of Web sites, or 
part of a Web site is, say, accessible, about a given subject, created 
by a named author, safe for children, recognised by a trustmark etc. 
This data can be used to decide to include a given URL in search 
results, pop an icon in the browser chrome etc. In other words, the 
outcome of processing the data is an action. So it's in the application 
that you need a rule, like 'if the URL is mobileOK and age-appropriate, 
include in the search results' - which is not for POWDER to do.

The output of a DR expressed as a rule is going to be the input to 
another rule. I'd rather skip that and encode the data that can itself 
be the input to a single rule that makes sense within the application.

2. People creating DRs, even if they use a tool to do so, should be able 
to understand what the DR says. The more complex the actual DR is, the 
less we achieve this. The basic concept of A being a sub class of B and 
who says that A is a sub class of B is simple enough to put across to 
tech and non-tech people alike.

Phil.


Andrea Perego wrote:
> Thanks, Stasinos.
> 
> So, for the moment, we have two different proposals of how a DR scope
> should be specified:
> 
> 1. By using class axioms [1] (i.e., by describing the characteristics of
> a class of resources):
> 
> <owl:Class rdf:ID="ResourceOnExampleDotOrg">
>   <owl:equivalentClass>
>     <owl:Restriction>
>       <owl:onProperty rdf:resource="&wdr;includeHost" />
>       <owl:hasValue>example.org</owl:hasValue>
>     </owl:Restriction>
>   </owl:equivalentClass>
> </owl:Class>
> 
> 2. By using individual axioms [2] (i.e., by describing the
> characteristics of the resources which are instances of a possibly
> undefined class):
> 
> <owl:Class rdf:ID="ResourceOnExampleDotOrg">
>   <wdr:includeHost>example.org</wdr:includeHost>
> </owl:Class>
> 
> 
> Stasinos, you clearly explained the semantic difference between those
> two options, but it is not clear to me why you think that option 2 is
> preferable.
> 
> Could you please explain this?
> 
> Andrea
> 
> 
> [1]http://www.w3.org/TR/owl-ref/#ClassAxioms
> [2]http://www.w3.org/TR/owl-ref/#Individual
> 
> 
> 
> Stasinos Konstantopoulos wrote:
>> On Thu Dec  6 23:32:06 2007 Andrea Perego said:
>>
>>>> Or s'thing like declaring an RDF meta-property that has owl:Class as
>>>> it's domain:
>>>>
>>>> <rdf:Property rdf:ID="includesHost">
>>>>   <rdfs:domain owl:Class"/>
>>>>   <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
>>>> </rdf:Property>
>>>>
>>>> <owl:Class rdf:ID="FOSIchildSafe">
>>>>   <rdfs:subClassOf wdr:ChildSafe/>
>>>>   <wdr:includeHost>example.org^^xsd:string</includesHost>
>>>> </owl:Class>
>>> Well, this allows me to ask you a new question.
>>>
>>> In the POWDER vocabulary [1], we have defined the equivalent of the new
>>> wdr:includeHost:
>>>
>>>   <owl:DatatypeProperty rdf:about="&wdr;includeHosts">
>>>     <rdfs:isDefinedBy rdf:resource="&wdr;" />
>>>     <rdfs:label xml:lang="en">include hosts</rdfs:label>
>>>     <rdfs:comment xml:lang="en">This property ...</rdfs:comment>
>>>     <rdfs:range rdf:resource="&wdrd;uriHostList" />
>>>     <rdfs:subPropertyOf rdf:resource="&wdr;addressRestriction" />
>>>     <rdfs:seeAlso rdf:resource="&group;#byURIcomp" />
>>>   </owl:DatatypeProperty>
>>>
>>> The new definition should then be something like what follows:
>>>
>>>   <owl:DatatypeProperty rdf:about="&wdr;includeHost">
>>>     ...
>>>     <rdfs:domain rdf:resource="&owl;Class" />
>>>     <rdfs:range rdf:resource="&xsd;string" />
>>>     ...
>>>   </owl:DatatypeProperty>
>> No nit-picking on whether it's going to be includeHosts (range is RDF
>> List) or includeHost (range is XML string), come to think of it, I don't
>> see any reason not to retain the RDF List range. I am not persuaded that
>> it should be owl:DatatypeProperty in addition to being some
>> POWDER-specific sub-property of rdf:Property, say
>> wdr:addressRestriction, but that is a different issue.
>>
>> The key difference is that the domain is owl:Class instances, as opposed
>> to owl:Thing instances. Let me explain: OWL instances and OWL classes
>> are symbols taken from distinct alphabets, that is, a class symbol
>> cannot be confused for an instance symbol and vice-versa. But if one
>> looks under this layer of OWL semantics, they are all RDF instances: OWL
>> class symbols are instances of the owl:Class class, which is a subclass
>> of the rdf:Class class and OWL instance symbols are instances of the
>> owl:Thing class.
>>
>> Now,
>>
>>> You then say that the DR scope definition can be:
>>>
>>>   <owl:Class rdf:ID="FOSIchildSafe">
>>>     <wdr:includeHost>example.org</wdr:includeHost>
>>>   </owl:Class>
>>>
>>> My question is: given that the wdr:includeHost property is defined as
>>> above, is this equivalent or not to writing:
>>>
>>>   <owl:Class rdf:ID="ResourceOnExampleDotOrg">
>>>     <owl:equivalentClass>
>>>       <owl:Restriction>
>>>         <owl:onProperty rdf:resource="&wdr;includeHost" />
>>>         <owl:hasValue>example.org</owl:hasValue>
>>>       </owl:Restriction>
>>>     </owl:equivalentClass>
>>>   </owl:Class>
>> Not at all. In the former case includeHost is a property of an owl:Class
>> instance, whereas in the latter it is a property of all owl:Thing
>> instances that are members of an owl:Class instance. Huge difference: in
>> the former case you are saying something about the class (the container,
>> the box) without saying about its instances (the things in the box). You
>> might have as well said that this box is shiny, or black, or whatever,
>> and wouldn't have gotten any wiser about what kinds of things are in the
>> box.
>>
>> In the latter case you are not describing the class (the container), but
>> rather the things that are in it. By doing so, you are creating the
>> (false) impression that you have provided a touchstone for membership in
>> the class. Which it is not, as sample.example.org also belongs in this
>> class (according to the intended semantics), but you have no means of
>> expressing in OWL that includeHost X.Y.Z implies includeHost Y.Z.
>>
>> OWL with rules might cut it, but then Phil will point out that you have
>> no standard (or at least W3C recommended) means of expressing rules.
>>
>>> In other words, do we really need to use owl:Restriction?
>> In my view, we need to avoid it.
>>
>> s
>>
>>
>>
> 

-- 
Phil Archer
Chief Technical Officer,
Family Online Safety Institute
w. http://www.fosi.org/people/philarcher/

Received on Monday, 10 December 2007 14:19:09 UTC