- From: pat hayes <phayes@ai.uwf.edu>
- Date: Mon, 24 Feb 2003 14:45:25 -0600
- To: Dan Connolly <connolly@w3.org>
- Cc: w3c-rdfcore-wg@w3.org
>In DAML+OIL, we had item, inferred from first/rest... > ><rdf:Property rdf:ID="item"> > <rdfs:comment> > for item(L, I) read: I is an item in L; either first(L, I) > or item(R, I) where rest(L, R). > >http://www.daml.org/2001/03/daml+oil#item >http://www.w3.org/TR/2001/NOTE-daml+oil-reference-20011218 > >In RDFS, member seems to have no relation to first/rest... >http://www.w3.org/TR/2003/WD-rdf-schema-20030123/#ch_member >http://www.w3.org/TR/rdf-schema/#ch_collectionvocab >http://www.w3.org/TR/2003/WD-rdf-schema-20030123/#ch_collectionvocab > >I thought rdfs:member was specified ala daml:item >to be inferred from first/rest. My understanding is that rdfs:member is the superproperty of all the container membership properties rdf:_1 etc, and has nothing to do with collections. Our collections practically have no semantics, remember: we don't even require that rdf:first be functional. > >I did some implementation assuming those semantics... >I was given a collection of a WG's documents, >and I just wanted the documents. There's no single >property that will get me from the WG to the documents, >so I used rules to make up the difference... > >------ >{ > :GROUP a org:WorkingGroup; con:homePage :PG. > > :F is log:semantics of [ a :GroupKB]. > > > (:F { this log:forAll :L, :X. > { :L l:first :X } log:implies { :L l:item :X }. > { :L l:rest [ l:item :X ] } log:implies { :L l:item :X }. > }) log:conjunction [ log:conclusion :FLists ]. > > :FLists log:includes { > [ a org:WorkingGroup; > con:homePage :PG; > wgi:hasDrafts [ l:item :WORK ] > ] > }. >} > log:implies { :GROUP org:deliverable :WORK }. >------- > >... but that seems like a big hassle when the RDF >parser could have just spit out rdfs:member triples >along with rdf:first and rdf:rest triples. > >In sum... > > (1) pls specify that rdfs:member connects collections > to their members First we gotta say what counts as a member. Then we gotta have a *recursive* definition of member. Then do we have to somehow justify that this definition always works? even on forked-tail lists and other exotica? > > (2) specify that parsers spit out rdfs:member triples > when parsing Collection syntax. > > (3) specify that parsers spit out rdfs:member triples > for old-style _n Containers too. Why would a parser do it? Those are entailments (via rdfs:subPropertyOf). Pat > >Hmm... I suppose there could be missing member triples >if the RDF/XML syntax used explicit first/rest or >explicit rdf:_n triples. But that seems acceptable >to me. > >This idea is probably too late to be worth the trouble. >But it comes from real implementation experience, >and I figure I ought to report the experience, >even if the WG decides it's not worth the change >at this point. > > >-- >Dan Connolly, W3C http://www.w3.org/People/Connolly/ -- --------------------------------------------------------------------- IHMC (850)434 8903 or (650)494 3973 home 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32501 (850)291 0667 cell phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes s.pam@ai.uwf.edu for spam
Received on Monday, 24 February 2003 15:46:03 UTC