- From: Dan Brickley <danbri@w3.org>
- Date: Tue, 12 Jun 2001 17:01:02 -0400 (EDT)
- To: <guha@alpiri.com>
- cc: Aaron Swartz <aswartz@upclink.com>, Graham Klyne <Graham.Klyne@baltimore.com>, <w3c-rdfcore-wg@w3.org>
On Tue, 12 Jun 2001, R.V.Guha wrote: > My suggestion is to purge it from the M&S spec > and add an appendix showing how containers > can be implemented on top of the smaller healthier RDF. Er, that was my suggestion. The one you disagreed with :) [[ (that's a little stronger, but i think we basically agree...) We don't want it all to go away, just to "go away" from that (central, foundational) section of the spec. As DanC noted last week, there are some constraints, such as that being the n-th member of a container is a uniquely identifying property (ie. that each rdfs:ContainerMembershipProperty is a daml:FunctionalProperty ((?)), which will need to be written down somewhere in one of the WG's specs... ]] ("...need to be written down somewhere in one of the WG's specs") In other words: the RDF Core WG owns both the RDF Model and Syntax spec and the RDF Schema spec, and is chartered to repartion M+S if necessary, see http://www.w3.org/2001/sw/RDFCoreWGCharter 'deliverables': - ... - update the RDF Model and Syntax Specification (as one, two or more documents) clarifying the model and fixing issues with syntax - complete work on RDF Schema 1.0 Specification [...] So we can describe the container stuff quite separately from the basic formal model; my inclination would be to put it in the RDF Schema doc, since that doc already has a section describing RDF M+S's container vocab. > What does it buy us? Makes the spec simpler, easier > to understand, implement, ... you're preaching to the converted :) danbri > guha > > Dan Brickley wrote: > > > hi > > > > On Tue, 12 Jun 2001, R.V.Guha wrote: > > > > > Actually, no. I do mean it. It should all *completely* go away.guha > > > > Forgetting reification for now, are you saying that we should completely > > drop *all* mention of the RDF container machinery (bag/seq/alt/li and > > syntactic support)? Unless you can show them to be undeployed and broken > > beyond repair, this seems to me to go beyond our charter. RDFCore is a > > clean-up operation not a rewrite. More importantly, dropping containers > > would be somewhat over the top: the main problem with the container stuff > > is the central role that M+S gives it. As a handy (if quirky) piece of > > vocab it is often useful (eg. as deployed in the RSS 1.0 spec, > > http://purl.org/rss/1.0/). I believe we can re-present RDF in terms of a > > slimmed down formal model spec plus and syntax and various bits of > > utility vocab (schema stuff, containers etc). I don't really see what > > purging containers entirely from our specs would buy us... > > > > (forgive me if i misread your comment) > > > > Dan > > > > > Dan Brickley wrote: > > > > > > > > > My claim was pretty modest: just that both rdf:type and rdf:_n constructs > > > > > > are similarly privileged in RDF's XML syntax, but that neither deserve > > > > > > any special architectural privilege w.r.t. the basic formalities of the > > > > > > triples model. Whether we feel the one is more/less useful, intuitive etc > > > > > > is a separate issue, and one that you're right to postone to future work > > > > > > on syntax beautification. > > > > > > > > > > > > Dan > > > > > > > > > Amen. Stated differently, everything not in the first box > > > > > in section 5 of the M&S spec should go away from the spec > > > > > > > > > > guha > > > > > > > > (that's a little stronger, but i think we basically agree...) > > > > We don't want it all to go away, just to "go away" from that (central, > > > > foundational) section of the spec. As DanC > > > > noted last week, there are some constraints, such as that being the n-th member > > > > of a container is a uniquely identifying property (ie. that each > > > > rdfs:ContainerMembershipProperty is a daml:FunctionalProperty ((?)), > > > > which will need to be written down somewhere in one of the WG's specs... > > > > > > > > danbri > > > >
Received on Tuesday, 12 June 2001 17:01:13 UTC