RE: 2 RDF Schema Questions: defining a property to contain a value that is anonymous, and ORing rdfs:domain?

> 1. Suppose that I have an RDF/XML instance that contains a Length
> property:
>
>      <Length>
>           <rdf:Description>
>                <rdf:value>6300</rdf:value>
>                <uom:units>kilometers</uom:units>
>           </rdf:Description>
>      </Length>
>
> As you can see, the contents of Length is an anonymous resource.
>
> How should Length be defined in an RDF Schema?  Here is how I imagine
> that it should be defined:
>
>      <rdf:Property rdf:ID="Length">
>         <rdfs:domain rdfs:resource="#River"/>
>     </rdf:Property>
>
> Note that I do not specify an rdfs:range value, thus Length can have any
> value.  Is this the proper way to define a property with a value that is
> an anonymous resource?

Only if you are okay with <Length>6300km</Length> being used as well.

"Anonymous" generally refers to the fact that we do not have a URI for the
resource (which does not mean there are no URIs that identify them, only
that we don't know them).

I think you are using it to mean that we don't have the class name used.
However that doesn't mean that it is not of any class, merely that we don't
know what class it is of (all resources are of the Resource class, and a few
others as well, only a couple at most of these are something we are
interested in though).

If you wanted to you could define a class (say "Distance") and then use:

<rdf:Property rdf:ID="Length">
	<rdfs:domain rdf:resource="#River"/>
	<rdfs:range rdf:resource="#Distance"/>
</rdf:Property>

Note that this does not force you to use <Distance> in the RDF/XML fragment
above, you can keep the RDF/XML you have already and infer that it is of
type #Distance if and when you need to know that.

> Similarly, above it shows a property uom:units within the anonymous
> resource.

Creating the #Distance class solves this problem as well. Again it does not
require you to use that class in the actual RDF/XML if that is undesirable
for some reason.

> 2. Consider this property definition of FlowRate:
>
> <rdf:Property rdf:ID="FlowRate">
>   <rdfs:range rdf:resource="http://.../rdf-schema#Literal"/>
>   <rdfs:domain rdf:resource="#River"/>
>   <rdfs:domain rdf:resource="#Brook"/>
> </rdf:Property>
>
> Note the two rdfs:domain statements.  This says that the property
> FlowRate may be used with a class that is a River AND a Brook.
>
> How do I define FlowRate so that it may be used with either a River
> class OR a Brook class?
>
> Is this the way to do it:
>
> <rdf:Property rdf:ID="FlowRate">
>   <rdfs:range rdf:resource="http://.../rdf-schema#Literal"/>
> </rdf:Property>
>
> <rdf:Property rdf:about="#FlowRate">
>   <rdfs:domain rdf:resource="#River"/>
> </rdf:Property>
>
> <rdf:Property rdf:about="#FlowRate">
>   <rdfs:domain rdf:resource="#Brook"/>
> </rdf:Property>
>
> Note that I defined the FlowRate property first and then I "added to it"
> using two more property definitions.  Is this how ORing is achieved?

The two pieces of RDF/XML are completely equivalent. When you parse them
into triples they both produce:

<#FlowRate> <rdf:type> <rdf:Property> .
<#FlowRate> <rdfs:range> <rdfs:Literal> .
<#FlowRate> <rdfs:domain> <#River> .
<#FlowRate> <rdfs:domain> <#Brook> .

(the second example produces the first triple three times, but the
duplicates can be ignored).

The reason that this is effectively an AND is that any of those can be used
in isolation as appropriate (say to identify which resources are Rivers
independent of whether or not <River> is used in the RDF/XML).

DAML+OIL and OWL both provide ways of defining classes that are unions of
other classes:

<rdfs:domain>
	<owl:Class>
		<owl:unionOf rdf:parseType="Collection">
			<owl:Class rdf:resource="#River"/>
			<owl:Class rdf:resource="#Brook"/>
		</owl:unionOf>
	</owl:Class>
<rdfs:domain>

If you wish to just use RDFS rather than DAML or OWL (or if you wish to
provide the above as best you can in RDFS for use by applications that only
support RDFS) then you can do this:

<rdf:Description rdf:ID="RiverOrBrook"/>
<rdfs:Class rdf:ID="River">
	<rdfs:subClassOf rdf:resource="#RiverOrBrook"/>
</rdfs:Class>
<rdfs:Class rdf:ID="Brook">
	<rdfs:subClassOf rdf:resource="#RiverOrBrook"/>
</rdfs:Class>
<rdf:Property rdf:ID="FlowRate">
	<rdfs:range rdf:resource="http://.../rdf-schema#Literal"/>
	<rdfs:domain rdf:resource="#RiverOrBrook"/>
</rdf:Property>

#RiverOrBrook is merely used to be a common superclass of #River and #Brook
that is the domain of #FlowRate. I don't even bother to say anything about
it, though I have a piece of XML with that id so that there is something
that can be identified as having that ID by XML tools (in practice I'd
probably use <rdfs:Class rdf:ID="RiverOrBrook"> for clarity, but I didn't
here just to show that the use of rdfs:Class is redundant).

Note that while this allows either #River or #Brook to be used here it
doesn't exclude the possibility that there may be another class which isn't
a subClassOf those classes but which is a subClassOf #RiverOrBrook, and can
hence have a #FlowRate. If this is undesirable then only the DAML+OIL or OWL
method will perfectly match your intentions. However arguably it would be
beneficial to allow either yourself or someone else to later define
#UndergroundStream or whatever and allow it to have a #FlowRate by making it
a subClassOf #RiverOrBrook.

Received on Thursday, 20 February 2003 07:14:23 UTC