W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > April 2002

Proposal submissions (was: Re: Range constraints on collection members)

From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
Date: Sat, 06 Apr 2002 08:14:40 +0100
Message-Id: <5.1.0.14.2.20020406075825.00a09250@joy.songbird.com>
To: Patrick Stickler <patrick.stickler@nokia.com>
Cc: RDF Core <w3c-rdfcore-wg@w3.org>
This note is less about the merits of the particular case raised than a 
general comment about W3C process.  I'm hoping some W3T folks who follow 
this can clarify process matters.

It seems to me that however much we define, there will always be more good 
ideas.

If this were the IETF (which is open to submissions from anyone), I'd say 
to Garrett (or to you, Patrick):  write up your proposal as a draft in the 
general form of an extension to the RDF standard documents (using the same 
notation conventions, document layout, etc.) and request publication as a 
draft.  If the case made was *really* compelling, the WG might then choose 
to adopt it into the current revision of specification.  More likely, if 
the case is moderately compelling then the idea may be adopted as a future 
enhancement to the specification.  Anyway, a published specification in the 
right general format provides a "highest point of departure" for future 
work on the topic covered.  Having an implementation would enhance the 
specification's credibility.

W3C has a process for submission of NOTESs, but (a) it is fairly 
heavyweight, and (b) AFAIK it is only available to W3C members and 
team.  But that seems to be the nearest equivalent.  (Alternatively, I 
suppose such an individual might write up such a proposal, publish it on 
their own web site, and post a link to the appropriate www-*-comments list, 
but it seems that such proposals are more likely to be overlooked.  Maybe 
allow some related-submissions links fromn the WG home page?)

Anyway, returning to the particular point raised:  there is no reason that 
the suggested rdfs:containerRange could not be specified (apart from the 
namespace) separately, used privately and also submitted for consideration 
by the present/future working group.  If the proposal is subsequently 
adopted into the rdfs: namespace then the early implementers have a 
URI-mapping problem - I see no way to avoid that.

#g
--

At 06:31 AM 4/5/02 +0300, Patrick Stickler wrote:
>On 2002-04-04 22:51, "ext Graham Klyne" <Graham.Klyne@MIMEsweeper.com>
>wrote:
>
> > At 06:02 PM 4/4/02 +0100, Brian McBride wrote:
> >> RDF Schema Issues
> >>
> >>     * rdfs-constraining-containers: Should it be possible to constrain
> >> the members of a container to be of a given type?
> >
> > I have a vague recollection we'd decided to defer this one??  (i.e. that
> > RDFS 1.0 would provide no such capability.)
>
>I just recieved email from an implementor, Garret Wilson at Global Mentor,
>that this is sorely needed for what they are doing.
>
>I encouraged him to post a summary of the issue to RDF comments.
>
>My present take on this is that we need an additional constraint
>property that applies to containers, such as rdfs:containerRange
>which would be used in conjunction with rdfs:range.
>
>We can't simply extend the semantics of rdfs:range to collections
>because one may wish to say that a property must take a collection,
>not just a single value, and thus, rdfs:range breaks. What is
>needed is an additional constraint mechanism, such as something
>like rdfs:collectionRange which would apply to the members of
>a collection. One would then specify e.g. that the property's
>rdfs:range would be rdf:Bag and the rdfs:collectionRange would
>be xsd:string, etc.
>
>If the rdfs:range is xsd:string, then a value of rdf:Bag is in
>fact a range violation since an instance of rdf:Bag is not
>an instance of xsd:string.
>
>Eh?
>
>Patrick
>
>--
>
>Patrick Stickler              Phone: +358 50 483 9453
>Senior Research Scientist     Fax:   +358 7180 35409
>Nokia Research Center         Email: patrick.stickler@nokia.com

-------------------
Graham Klyne
<GK@NineByNine.org>
Received on Saturday, 6 April 2002 04:15:51 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:47:23 EDT