Re: URI groups

Incidentally, the RDF graph of my example looks right - but that's just 
the RDF...

http://www.w3.org/RDF/Validator/ARPServlet.tmp/servlet_14339.png

Phil Archer wrote:
> 
> 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

Received on Monday, 10 December 2007 15:06:29 UTC