Re: Review of MT

>Comments on Model Theory Editors draft
>======================================
>http://lists.w3.org/Archives/Public/www-archive/2002Jan/att-0007/01-RDF_Mode
>l_Theory.htm
>
>
>Of course, overall unreserved compliments ...
>
>I'll divide my comments into things that look to me like errors,
>some stylistic points, and an enhancement request for next time.
>
>
>Errors?  (For all of these I defer to Pat's judgement)
>======================================================
>
>Section 1.4, last line, I made it "none of the above"  instead of
>"only one of the above".

Damn, you are right. And the same mistake is reflected in the second 
example. Thanks for noticing. I will fix this.

>[]
>
>Section 2. Delete all comments to do with tidiness.
>Delete the word "tidy" from the definition of skolemization.

Right.

>[]
>
>Counterexample to Anonymity lemma 1:
>
>E =
><a> <b> _:c .
><a> <b> <c> .
>
>E' =
><a> <b> <c> .

Ah, clever. Right, obviously. I need to restate those lemmas more 
carefully. That phrase "is like E except" is much too sloppy, in any 
case. I will get these fixed. Similarly for the next one.

>[]
>
>Counterexample to Anonymity lemma 2:
>
>E =
><a> <b> _:c .
>_:c <d> <e> .
><a> <b> _:d .
>
>
>E' =
><a> <b> _:c .
>_:c <d> <e> .
>[]
>
>End of section 5 (penultimate para).
>"Since these clearly ...".
>No they don't.
>I don't see
>IEXT(I(rdf:type)) contains <x,I(rdf:Property)> iff x is in IP
>(I think this should be explicitly added).

That follows from ICEXT(I(rdf:Property)) = IP . I will add a comment 
to clarify this.


>[]
>
>
>Style comments
>==============
>(Note: Pat writes substantially more clearly than I do, and hence should
>probably discard at least half of my style comments!)
>
>(Excessive use of bracketed text. I (particularly) dislike the doubly
>nested use of brackets).

Yes, I'm aware of this stylistic failing. I will go through and do a 
bracketting-purge.

>
>I think deleting all brackets around complete paragraphs would be an
>improvement. (Even your asides, Pat, deserve our full attention :) ).
>
>In section 0.2 para "To indicate blank nodes ..." I suggest that the
>bracketed text "(However, we ... brevity.)" be pulled out as a separate
>unbracketed paragraph.
>
>In section 1.2 para "We do not take ..." I suggest replacing "(If" by
>"Alternatively, if" and deleting the matching paranenthesis.
>
>In section 1.3 first para I found the bracketed text "(For a lexicalized
>... lexicalization.)" unclear. I think it would be better somewhat more
>concrete e.g. "For an interpretation of the graph corresponding to an
>N-triple document it is normal to use a vocabulary consisting of the
>set of urirefs occurringin the document."

OK, this is rather tortuously written. I will rewrite.

>When I got to section 1.3 I was surprised by XL - I had missed its
>introduction. Should links or more headings be used to help the reader
>around the document?

OK, I can add more internal links. Good idea. (Im still rather new to 
hypertext composition.)

>
>Section 2.2 first para repeats fourth para of section 0.2.

Whoops. Will fix.

>It was OK,
>but could possibly be improved ...
>Section 5, just above the table, "Note, these ... ".
>This refers to the old RDF Schema spec as if there were no other.
>(Well there isn't!) But I understand our intent is that there will
>be, and then this para will read quite strangely.

OK, then we can change it in the newer version, right? Or would it be 
better W3C style to refer ahead to future documents (? genuine 
question, Im not sure how best to handle this 'evolving' 
documentation process.)

>RDF Schema has not yet made it to full rec. largely because it needed
>this change.
>
>Enhancment Request
>==================
>
>I was disappointed that no account was offered of the relationship
>between:
>
><a> <rdf:type> <rdf:bag> .
><a> <rdf:_1> <b> .
><a> <rdf:_2> <c> .
>
>and
>
><a> <rdf:type> <rdf:bag> .
><a> <rdf:_2> <b> .
><a> <rdf:_1> <c> .
>
>My belief is that we either need to offer such an account
>or drop rdf:bagID from the syntax. In certain cases a parser
>may produce either from identical input.

I agree this is an oddity.

I think the best thing is if I simply remove this section for now 
until we get containers fully worked out. The point of sneaking it in 
wasn't really to imply that containers are a done deal, but only to 
show that they don't seem to give rise to any MT problems; they are 
(at least in a simple version) almost semantically transparent. BUt 
since you want bags to be more baglike, and Jos wants URIs to be able 
to denote sets of triples, and so on, then maybe my optimism here is 
rather naive.

Pat
-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Friday, 18 January 2002 11:42:19 UTC