Re: Enumerations

Tom Van Eetvelde wrote:

> Hello Mark,
>
> It is not only a matter of syntax.
>
> I could easily fool the current system by writing:
>
>  <s:maritalstatus rdf:resource="Nonsense"/>
>
> The parser looks at the type of the resource, which is 'maritalstatus' and is satisfied. It cannot
> check if Nonsense really is intended to be a correct instance of the class MaritalStatus. In order
> to do this, it has to run through x amount of schema's to look for all allowed instances of
> maritalstatus.

All the schema you need to validate the value of maritalstatus is clearly illustrated in CR-rdf-schema:

<rdf:Property ID="maritalstatus">
  <rdfs:range rdf:resource="#MaritalStatus"/>
</rdf:Property>

[...]

<rdfs:Class rdf:ID="MaritalStatus"/>
<MaritalStatus rdf:ID="Married"/>
<MaritalStatus rdf:ID="Divorced"/>
<MaritalStatus rdf:ID="Single"/>
<MaritalStatus rdf:ID="Widowed"/>


>
> When using bags for your enumerations, all allowed elements are bundled. The RDF supports bag
> elements easier than class instances. Just look at the graph picture: get me all bag elements is
> just following the 'li' arcs to their values. Get me all class instances is starting from the
> classtype and reversing all arc arrows. Class instances have more chance of being scattered around
> then bag elements.

I somewhat agree with this, but you give up extensibility, inheritance, etc.

>
>
> What is more: if you are always going to hang types to property values, then you might as well say
> goodbye to Literals as they will never be used anymore.

I don't think anyone would advocate making a class for every instance of "GivenName", "Surname",
"CompanyName", etc...

>

> I believe sets of literals should not always
> be encapsulated in a class. This looks a bit unnatural sometimes.
>
> If you want a person to make a choice out of getting: a car, a travel ticket, a movie, a new
> haircolour. Are you going to stuff al these choices in a class?

But you just argued above that it's good to use a bag because all the allowed values are together.

I think what's really missing is a contstraint property that closes the set of class instances!

> I guess not. I think you just want a
> wrapper called 'Choices' and paste all the elements in it. When creating classes, you focus on
> objects sharing some property. You could always look for some artificial link between the elements
> of Choices and use this as an argument to create a class, but then again, that smells like an
> unnatural implementation. It even gets messier if the elements of 'Choices' are classes themselves.

Messier or more powerful, depending on your aesthetic sensibilites.

>
>
> The latter is the fundamental reason why I was looking for a natural implementation of enumerations
> (which also supports enumerations of classes and even classes/Literal mixes). This is just my
> opinion of course.
>
> regards,
>
> Tom.
>
> Mark Grossman wrote:
>
> > Making enumerants be members of a class seems like the perfect application of existing RDFS
> > constructs, and I don't see the syntax
> >
> >    <s:maritalstatus rdf:resource="Single"/>
> >
> > any more burdensome than
> >
> >    <s:maritalstatus>Single</s:maritalstatus>
> >
> >    -- Mark
> >
> >

--
Mark Grossman
Geocast Network Systems       Tel: (650)566-3259
190 Independence Dr.          Fax: (650)566-8112
Menlo Park, CA 94025          E-Mail: msg@geocast.com