Re: DR structure debate: summary and conclusion

Thanks for this summary, Phil. Just a few notes.

> [snip]
> 
> Note that there is no data in the example Description Resource to tell a
> user agent who created the Descriptive and Resource Set classes. If
> desired, this can be provided in a couple of ways. Firstly by further
> reification statements such as
> 
> <rdf:statement>
>   <rdf:subject rdf:resource="#ResourceOnExampleDotOrg />
>   <rdf:predicate rdf:resource="http://www.xmlns.com/foaf/0.1/maker" />
>   <rdf:object rdf:resource="http://www.example.com/foaf.rdf#david">
> </rdf:statement>

I must correct this statement. It does not says that David made the
definition of class with rdf:ID "ResourceOnExampleDotOrg". Rather, it
means that David is the author of all the instances of that class -
i.e., David is the author of all the resource hosted by example.org. In
other words, it corresponds to the following statement:

  <owl:Class rdf:ID="ResourceOnExampleDotOrg">
    <foaf:maker rdf:resource="http://www.example.com/foaf.rdf#david" />
    ...
  </owl:Class>

By contrast, in order to say that David defined class
"ResourceOnExampleDotOrg" we need to specify a rdf:Statement for each of
the statements defining that class.

So, if the following is the class description:

1  <owl:Class rdf:ID="ResourceOnExampleDotOrg">
2    <owl:equivalentClass>
3      <owl:Class>
4        <rdfs:subClassOf>
5          <owl:Restriction>
6            <owl:onProperty rdf:resource="&wdr;includeHost" />
7            <owl:hasValue>example.org</owl:hasValue>
8          </owl:Restriction>
9        </rdfs:subClassOf>
10     </owl:Class>
11   </owl:equivalentClass>
12 </owl:Class>

we have first to associate an rdf:ID to each property used in the class
description:

1  <owl:Class rdf:ID="ResourceOnExampleDotOrg">
2    <owl:equivalentClass rdf:ID="p1">
3      <owl:Class>
4        <rdfs:subClassOf rdf:ID="p2">
5          <owl:Restriction>
6            <owl:onProperty  rdf:ID="p3" &wdr;includeHost" />
7            <owl:hasValue rdf:ID="p3">example.org</owl:hasValue>
8          </owl:Restriction>
9        </rdfs:subClassOf>
10     </owl:Class>
11   </owl:equivalentClass>
12 </owl:Class>

and then specify what follows:

<rdf:Description rdf:about="#p1">
  <foaf:maker rdf:resource="http://www.example.com/foaf.rdf#david">
</rdf:Description>

<rdf:Description rdf:about="#p2">
  <foaf:maker rdf:resource="http://www.example.com/foaf.rdf#david">
</rdf:Description>

<rdf:Description rdf:about="#p3">
  <foaf:maker rdf:resource="http://www.example.com/foaf.rdf#david">
</rdf:Description>

> Alternatively, if it is true that all the data was created by the same
> entity, then one can simply include a description of the RDF instance
> itself thus:
> 
> <rdf:Description rdf:about="">
>   <foaf:maker ....
>   ...
> </rdf:Description>
> 
> It may also be appropriate to use owl:Ontology but this should be done
> with caution since the statements about the key assertion that one class
> is a sub class of another is outside the the usual understanding of the
> term ontology. foaf:Document may be appropriate, however.
> 
> [Incidentally, I think we should say that even if a DR is published
> within a single, self contained, RDF instance that includes a
> description of itself, the sub class relationship triple (line 23 above)
> MUST still be the subject of reification since the creation of the RDF
> instance is not the same as asserting the relationship. Plus, we need to
> be able to validate DRs and looking for the reification triples is
> central.]

Could you explain in more detail this point, Phil? As far as I
understand, if the Resource Set and Descriptive classes are in the same
RDF instance containing the statement concerning the sub class
relationship, writing this

<rdf:Description rdf:about="">
  <foaf:maker rdf:resource="http://www.example.org/foaf.rdf#david" />
</rdf:Description>

will make David the author of all of them.

I agree, however, that the rdfs:subclassOf statement linking the
Resource Set class to the Descriptive one, must have an rdf:ID, because
this will be the ID of the DR. Otherwise, we have no way to point at it.
Is this what you meant?

> The example above has been made as simple as possible to show the key
> features of the DR model but we should note here some of the more
> complex scenarios. Let's begin with a real example.
> 
> For the most part, my organisation's Web site does not contain any
> potentially offensive material and so is described using the ICRA
> vocabulary [2] as 'none of the above' in all categories. However... we
> do have several Associate Members whose products and services are not
> accurately described this way, and since we describe them and link to
> them from our site, we need different descriptors on all pages where the
> path starts with /associates.
> 
> From a POWDER perspective this means we have two sections of the same
> Web site that need to be sub classed to different Descriptors. Leaving
> out the detail we can achieve this by creating 4 classes:
> 
> 1 Class of Resource on fosi.org AND NOT path starts with 'associates'
> 
> *Disjoint with*
> 
> 2 Class of Resource on fosi.org AND path starts with 'associates'
> 
> 3 Class 'Child safe'
> 
> 4 Class 'not child safe'
> 
> 1 is made a sub class of 3, 2 is a sub class of 4. It is important that
> class 1 is fully defined including details of the exception (i.e. that
> the path must not start with 'associates'). Not to include this would
> mean that resources on fosi.org/associates were both child safe and not
> child safe at the same time. The 'disjoint with' statement is therefore
> critical.
> 
> There are other situations where you _do_ want more than one DR to apply
> to a given resource and this is readily achieved. For example, the whole
> of example.org may be about Gustav Mahler however the content may only
> conform to mobileOK where the path starts with /mobile. Then you'd create:
> 
> 1. Class of Resource on example.org
> 
> 2. Class of resource on example.org and path starts with /mobile
> 
> 3. Class of resources with the primary topic of Gustav Mahler
> 
> 4. mobileOK Class
> 
> Then make 1 a sub class of 3 and 2 a sub class of 4. Class 2 is now both
> about Gustav Mahler AND mobileOK which is what we wanted.

As far as I am concerned, I completely agree with this solution.

A last comment.

If I'm not mistaken, Stasinos raised some objections about using
properties like wdr:includeHost for denoting a set of resources. The
problem is that (correct me, Stasinos, if I'm wrong) a property like
wdr:includeHost has a semantics combining a statement concerning a
property of a resource (the URI host component) and a statement
enforcing pattern matching. So, instead of saying:

?resource wdr:includeHost "example.org" .

we'd rather say:

?resource wdr:host ?host . ?host string:endsWith "example.org" .

The above statement corresponds to the following procedure:
1. fetch the host component of the resource's URI and assign such value
to variable ?host
2. verify whether the value of variable ?host ends with "example.org"

It is important to make clear this point - deciding how the Resource Set
class is defined is then quite an urgent issue.  So, the problem is:

Can or cannot we use properties like wdr:includHost, as below?

1  <owl:Class rdf:ID="ResourceOnExampleDotOrg">
2    <owl:equivalentClass>
3      <owl:Class>
4        <rdfs:subClassOf>
5          <owl:Restriction>
6            <owl:onProperty
rdf:resource="http://www.w3.org/2007/05/powder#includeHost" />
7            <owl:hasValue>example.org</owl:hasValue>
8          </owl:Restriction>
9        </rdfs:subClassOf>
10     </owl:Class>
11   </owl:equivalentClass>
12 </owl:Class>

If we cannot, which are the alternative solutions?

Andrea

Received on Friday, 30 November 2007 00:01:33 UTC