Re: typed containers in RDF Schema

Brian,

Based upon your earlier comments (and others'), I was about to think that
maybe this could just be ignored or worked around for a while. But it's
starting to raise its head again. See below.

----- Original Message -----
From: "Brian McBride" <bwm@hplb.hpl.hp.com>
To: "Garret Wilson" <garret@globalmentor.com>; <www-rdf-comments@w3.org>
Sent: Saturday, April 06, 2002 2:44 AM
Subject: Re: typed containers in RDF Schema


> Hi Garret,
>
> At 09:06 05/04/2002 -0600, Garret Wilson wrote:
> >Imagine you have an RDF editor based on RDF Schema---you tell it the
schemas
> >you want to use, and it presents the appropriate editors for each
property.
> >For a "title" property, the editor would be a simple text field, as the
> >schema would indicate xsd:string as the range.
> >
> >But what would we do for a "keywords" property? This should be an rdf:Bag
of
> >related keywords,
>
> Why does it need to be a bag?  Could you make it simply a bunch of
repeated
> properties?

Your response seemed appropriate for "keywords", which is why I thought that
the issue might be miniscule. As we more fully develop the XPackage model,
though, this issue is coming back full force.

In XPackage, we have the concept of a "procession" in which content is
presented to the user as if it were "stitched" together. (We used to call
this a "spine" in the Open eBook world.) In essence, it's an rdf:Seq, and
I'll use that in the RDF Schema below. (Although we may wind up subclassing
rdf:Seq in the future to be an xpackage:Manifest, the concept remains the
same.)

<rdf:Property rdf:ID="procession">
  <rdfs:range rdf:resource="&rdf:Seq"/>
</rdf:Property>

We want to say that an electronic publication (or some other application of
XPackage) may have either a single procession/spine, or it may have several
alternate processions/spines (i.e. a textbook might combine its chapters in
different ways for different purposes). This means that, technically, the
range of "xpackage:procession" is either an rdf:Seq (the procession itself)
or rdf:Alt (a list of alternate processions, with the first one being the
default).

But writing the following schema, while technically correct, confuses the
semantics of what is happening by making it appear that one can simply use
an rdf:Seq or an rdf:Alt for "xpackage:procession". It also leaves out the
semantics of the type of values that can be used with rdf:Alt.

<rdf:Property rdf:ID="procession">
  <rdfs:range rdf:resource="&rdf:Seq"/>
  <rdfs:range rdf:resource="&rdf:Alt"/>
</rdf:Property>

In reality, we're simply trying to say that one can use a single rdf:Seq or
a list of alternate rdf:Seqs.

I'm not sure that an rdfs:collectionRange (which would apply to the members
of a collection, as others have suggested) would be a good idea, because
technically, it's not correct---a collection is a *class*, not a property,
and therefore doesn't have a range. What we're trying to specify is an
rdfs:collectionMemberRange, which is a *really* deep range specification, to
say the least. It introduces all sorts special casing for collections that
aren't valid for other classes.

> You could also define your own subclass of bag, bagOfStrings

...or in this example, our own subclass of an rdf:Alt, altOfSeqs (horrors
:) ). But this would require special semantics of the processor to recognize
that altOfSeqs is only restricted to rdf:li that have ranges of
rdf:Seq---nothing would actually be constrained by the RDF Schema.
Technically what is needed is a subclass of rdf:li (seqOnlyMember?) that has
a range of rdf:Seq, and then somehow subclass rdf:Alt to say that it only
has as properties seqOnlyMember, not normal rdf:li.

> or you could add a property to an ordinary bag to indicate the type of its
> membership.

...actually, we would have to indicate the range of each of its members---we
don't want to change the fact that the rdf:Alt, in this example, holds
rdf:li----we just want to say what their range is.

> The WG will consider this.  I'd appreciate your comments on whether
>
>   a) you need a standardized solution to this problem

Yes. Part of the buy-in we've been trying to get in the Open eBook Forum for
RDF is that it brings about a standardized structure for talking about
metadata---that it keeps us from writing our own framework to specify how
resources relate. (There has been, and still is, a large group that would
rather write a packing structure from scratch in XML rather than using RDF.)

>   b) it needs to be in rdf schema rather than an ontology language built
on top

Others have stated that this sort of thing is out of scope because RDF
Schema is meant to be simple---what I'm proposing is much too
complicated---and I had started to agree. I believe, however, that its
complications are overshadowed by two other important points: this use case
is *very* common, and it's analogous to features already in RDF Schema.

Let me state a subset of the use case this way: it is frequently desirable
to specify that a property can have a single, particular class as its
object, or that the property can have a single list of alternates of that
same particular class as its object.

Commonality: this pattern is seen over and over. Analogy: if an rdf:range
can be specified by a schema, it seems analogous that the schema can specify
that an alternate list of that same rdf:range can be specified.

Garret

Received on Friday, 3 May 2002 10:19:49 UTC