Re: Confusion about Collections

<snip>
> >
> > I need some clarification about your clarification.  I understand what
> > you say about the mapping between the RDF/XML of the collection and the
> > generated graph (there is one;  it's described in the Syntax
> > specification, but reading it isn't for the faint of heart), and I'm
> > concocting some words to try to describe it.  However, I'm not sure I
> > understand what you mean by the "long form" of the Collection.  It seems
> > to me that the graph is the "long form" (that is, it shows the consed
> > list, in all its "glory"), and there's a drawn graph in the Primer.  Are
> > you saying that a *triples* version of that graph would be clearer, and
> > would help people more than the drawing (he asked in astonishment)?  If
> > so, do you mean in addition to or instead of the drawing?
> >
>
> You're talking about the productions. I wouldn't recommend that for the
> Primer, or as you say, for the faint of heart or only for those intensely
> interested.
>
> People will programmatically access RDF as triples.

>But the triples are simply another way of describing the graph or,
>putting it another way, it's pretty straightforward to construct the
>triples from the drawing if you want to, but I suspect simply slopping
>all those triples down on paper isn't going to help very much, since
>there are no visual cues provided in triples.

What I'm trying to say is that one criticism of the RDF/XML is that the RDF
graph isn't clear from the RDF/XML. You show Collection and a listing of
resources, but the graph shows a collection type, and each resource is
connected to each other through a rdf:rest, and there's an implicit rdf:nil
at the end of the list, and then each resource points to a value and then to
a type and so on. That is what I meant be a disconnect between the graph and
the RDF/XML.

> And there is no mapping
> between the RDF/XML and the triples if I read the graph correctly.
>
snip

>Sure there is.  The property element with the rdf:parseType="Collection"
>attribute describes the property that points to the head of the list in
>the graph.  The resource descriptions nested in that property element
>are members of the collection.  For each one of those member resources,
>there's a corresponding resource of type rdf:List generated, with
>rdf:first and rdf:rest properties connecting it to the member and the
>rest of the list respectively.  To indicate the end of the list, you
>make rdf:rest property value be rdf:nil.  It may be that the use of
>s:student nested elements in the RDF/XML is causing the confusion.  I've
>changed the RDF/XML to:

<snip>

(same graph).


That's a lot to add to the model for parseType=Collection", isn't it?

Frank, I am trying to point out things in the documents that people who have
not lived and breathed RDF are going to get confused about. And I'm pretty
darn sure Collection is going to be one of them.

>
> I think it would help if you displayed the N-Tripes for the graph in
> addition to the graph. I think you also need to walk through each aspect
of
> the graph and explain what it means, and if there is an alternate syntax
for
> same (as there is with rdf:Bag).

>I think this would be devoting more space to Collections than they're
>probably worth.  I'll see.  But you can certainly construct your own
>list structures using your own vocabulary if you want to (e.g., two-way
>lists).

Again, trying to help point out areas that will generate confusion, and
concern.

>
> Also -- "Up to applications to interpret it". That's enough to ensure I
will
> never use Collections in my vocabularies. What a nightmare. This is the
same
> as relying on user agent's interpretation of <P> in the original HTML.

>This is no different than it being up to applications to interpret
>rdf:Bag and rdf:_1 though (and I know there's been a separate thread on
>this aspect of containers and reification, so we'll take it as read).

There is, and my attitude about all three now is that there is going to be
confusion and incompatibility about all three, then all three shouldn't be
used (as others have pointed out). And I'll write accordingly.
>
> Also, you introduced the term 'consed-pair' in the document to reflect
> Collections. This does need definition, it's not used anywhere else in any
> of the documents.
>

>What I said was that the RDF graph structure shown for collections was
>known as a "consed-pair" construction.  That's kind of a definition ("a
>consed-pair construction is one of these thingies") right?  I think what
>you mean is I should explain why it's *called* a "consed-pair"
>construction, but rather than waste the space on that, I'll take the
>term out.


Frank, does consed-pair add to the meaning of the Collection? If so, then
define it and say why you're using it for Collection. Don't necessarily drop
it. Are you getting charged for the square inch that the primer takes?

Look as I said earlier, I'm just trying to show you where you all are going
to have problems with the "mess of humans" that don't think RDF but will be
trying to use RDF/XML in the future.

Shelley

---------------------------------------------------
Shelley Powers             shelleyp@burningbird.net

Burning Bird Network: http://www.burningbird.net

Received on Monday, 25 November 2002 17:18:04 UTC