- From: Pierre-Antoine Champin <champin@bat710.univ-lyon1.fr>
- Date: Tue, 25 Apr 2000 11:25:05 +0200
- To: Jonas Liljegren <jonas@paranormal.se>, RDF Intrest Group <www-rdf-interest@w3.org>
Jonas Liljegren <jonas@paranormal.se>
> > Actually, I just saw I misunderstood you :
> > you were suggesting
> >
> > <rdf:Property ID="myprop">
> > <rdfs:range rdf:resource="&rdf;Seq"/>
> > <rdfs:containerRange rdf:resource="&rdf;Literal"/>
> > </rdf:Property>
> >
> > and I suggested
> >
> > <rdf:Property ID="myprop">
> > <rdfs:range rdf:resource="&rdf;Literal"/>
> > <rdfs:containerRange rdf:resource="&rdf;Seq"/>
> > </rdf:Property>
> >
> > The reason I prefer the second option is that rdfs:range
> > keeps addressing the atomic value(s) of the property, (for
> > either mono- or multi-valued properties)
> > and containerRange addresses the kind of multi-valuation
> > allowed.
>
> Containers are not only used because a subject has many objects with a
> specific property.
>
> How would you express the case there you always want the range to be a
> container, even if that container has one or no members?
Then I would write
<rdf:Property ID="myprop">
<rdfs:range rdf:resource="&rdf;Seq"/>
</rdf:Property>
but then I loose the information about the seq's elements type.
> My suggestion is backwards comaptible. A parser that doesn't support
> containerRange would still validate the model because the semantics of
> rdfs:range remains.
that's right ;
mine is not backward compatible because it allows 2 effective ranges
(atomic type OR container type) though RDFS can't allow that (range is
unique).
> I can't think of a good reason to allow both for a specific property.
simplicity. As an RDF user, I would rather type
<dc:Author> Pierre-Antoine </dc:Author>
than
<dc:Author> <rdf:Seq> <rdf:li> Pierre-Antoine </rdf:li> </rdf:Seq>
</dc:Author>
just because someone pointed out
that there MAY be more than one author !
Pierre-Antoine
Received on Tuesday, 25 April 2000 05:23:03 UTC