- 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