W3C home > Mailing lists > Public > www-rdf-interest@w3.org > September 2000

Re: Meaning of Alt

From: Tom Van Eetvelde <tom.van_eetvelde@alcatel.be>
Date: Tue, 26 Sep 2000 11:31:32 +0200
Message-ID: <39D06CF4.BFC34DC8@alcatel.be>
To: Graham Klyne <GK@dial.pipex.com>
CC: Ray Fergerson <fergerson@SMI.Stanford.EDU>, rdf interest <www-rdf-interest@w3.org>, Mor Peleg <peleg@SMI.Stanford.EDU>
Hello Ray, RDF comunity,

By coincidence I was looking at the same problem of enumerations. This is what I came up with in

First define the class 'Enumeration' in the following way:

<rdfs:Container rdf:ID="Enumeration">
    <rdfs:subClassOf rdf:resource="#Class"/>

Instances of 'Enumeration' are classes themselves via the 'subClassOf' property of 'Enumeration'.
'Days' can then be implemented as:

<rdfs:Enumeration rdf:ID="Days">
    <rdf:li> Monday </rdf:li>
    <rdf:li> Tuesday </rdf:li>
    <rdf:li> Wednesday </rdf:li>
    <rdf:li> Thursday </rdf:li>
    <rdf:li> Friday </rdf:li>

Whenever you have a property that needs to be restricted to the value sof Days, you can use the
'Range' property as Days is a class. Your application however needs to know that instances of 'Days'
are no longer resources, but literals. However, mapping literals to resources is not so difficult:
the schema foresees the class 'Literal', use the ID then to hold the actual value of your literal.
All these tricks have to be supported however by your application.

I prefer this approach over the one used in example 1 of the spec. Just listing all possible
instances of Maritalstatus has a big disadvantage. If this technique is used, you always need to
look in the schema for instance values of a class in order to do validation. It is obvious that this
approach is not scaleable.

Any comments on my proposal?

What strikes me here is the distance between "RDF is made to describe anything" and the actual
practice. Describing an enumeration should be easy as it is just a set of elements. Putting it in
RDF however makes things suddenly awkward. How can this be?



Graham Klyne wrote:

> At 04:12 PM 9/1/00 -0700, Ray Fergerson wrote:
> >A question about the semantics of the alternative collection type has
> >come up here.  We wanted to construct a model in which a property
> >could have a range of, for example, the days of the week.  One
> >possibility is to declare a Day_Of_The_Week class with instances
> >Monday, etc.  An example of this sort is given in the RDF spec.  In
> >our model though we really just need strings and not instances.  We
> >don't really want properties to be associated with these things.  We
> >initially thought that the Alt was an alternative (hummm) that would
> >allow us to just have strings.  A closer reading of the spec seems to
> >indicate though that the elements of an alternative collection are
> >meant to be equivalent is some way yet different in some other,
> >unspecified, way.  Thus you might imagine "Monday", "First workday",
> >"Lundi" as the elements of an Alt but not "Monday" and "Tuesday".
> >
> >Is this interpretation of Alt correct?  Are there other ways to
> >specify that the value of a property should be a single value from an
> >enumerated set (preferably of strings)?
> I tripped over a similar problem recently.  Your posting helped me clarify
> my thoughts.
> I think that describing a union data type and listing several alternative
> representations of what is essentially the same value are two very
> different functions that have somehow been conflated with the idea of
> 'alternative'.
> I think your (latter) interpretation is the only reasonable interpretation
> of rdf:Alt.
> I think your former idea needs to be treated as a *schema* issue rather
> than a *representation* issue.  And I think that 'rdf:Alt' is not part of
> the solution.
> I suspect that as and when the XML schema data type work is folded into
> RDF, that will provide a way to do what you want.  Per
> http://www.w3.org/DesignIssues/Evolution.html, I think we're operating at a
> level that still depends upon some degree of "Schema option 2".
> #g
> ------------
> Graham Klyne

Received on Tuesday, 26 September 2000 05:33:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:25 UTC