Re: Review of MT

>Review of Dec 14th MT draft:
>
>Note: these questions/comments are offered from the perspective
>of a non-mathematician reader, who has interest in understanding
>to some degree the MT.

Thats very useful, thanks.

>Stuff that is unclear to me due to language or presumed understanding
>of the field is likely to be unclear to others like me, and
>clarifications of such points would likely result in the MT being
>accessible to a broader audience.
>
>I can't say that I have understood all of the MT, but if my
>attempt at understanding all of it has provided some useful
>comments and suggestions, then I'm glad.
>
>If that broader audience (myself included ;-) is not of concern,
>then feel free to disregard any or all of the comments below...

I will reserve the right to decide that some points should be in the 
primer :-); but if the overall documentation is incomprehensible, 
then something needs to be done, for sure.

>From section 1.2:
>
>   "We simply assume a global set LV of literal values and a global mapping
>    XL from literal nodes to LV."
>   
>? Is a member of LV the lexical form (literal) or the member of the
>   value space of some datatype? If the former, then the term
>   "literal value" might be deemed misleading. Perhaps "lexical form"
>   or just "literal" would be clearer.

Latter. I will add words to clarify that.

>   If the latter is meant, then I don't see how that can be determined
>   without also including the identity of datatypes and their value
>   spaces into the mix, as a lexical form (literal) cannot map to
>   any actual value outside the scope of a given datatype's value
>   space.

Right, it isn't determined by the syntax; each interpretation 
"decides" it by fiat. It's not being decided by the syntax is 
reflected by there being a number of alternative interpretations; but 
each particular interpretation has everything 'decided' in this sense.

I will see if I can put some wording to try to make this clearer, but 
this is really something that should be expanded on in a primer or 
tutorial.

>
>In section 1.3:
>
>   "RDF as presently defined provides no syntactic means to distinguish
>    asserted from nonasserted triples..."
>
>? But isn't this what statement reification is for?

Well, some people think so and others do not. Reification is still 
murky, so Im steering clear of it for now.  (My own view is that 
reification is not an appropriate way to encode unasserted triples, 
by the way, but lets have that debate under another heading. )

>  To define triples
>   (statements) without asserting them? I.e. triples deriving from
>   <rdf:Description> are asserted but triples deriving from refication
>   (explicit or implicit by rdf:BagID) are not asserted.  ???
>
>In section 1.4:
>
>    "IS: a->1, b->1, c->2"
>
>* It would, IMO, be much better if the first example took some real
>   world RDF for the very first example so that it would be to some
>   degree recognizable to folks already familiar with RDF.

Yes, I was wondering about that. That means using 'real' URIs in the 
diagram rather than the a, b and c's. OK, I can do that.

>   Having right off the bat an example where a property has two
>   synonymous URIrefs is perhaps a little too much, and may throw
>   folks like me (i.e.  it threw me, at first ;-)

Ah, I hadn't thought of that as a problem. OK, I can make it simpler, I guess.

>
>   Rather perhaps an example with one property and two resources
>   and no synonymous IS mappings. Equality of URIrefs, i.e. that
>   two different URIrefs can denote the same "thing", could/should
>   be addressed later, if at all.

Well, I wouldn't want to give the impression that RDF assumed that 
URIrefs were unique names. In an ideal primer there would be a whole 
series of examples, but I don't think there is really room in this 
document for too much in the way of illustrative examples (?).

>
>In section 1.5:
>
>? Does your example "_:x a b . c b _:x ." extend from your
>   "a b c" example in 1.4?

Yes.

>  Or does it relate to the actual
>   interpretation of RDF?

Ummm. I'm not sure I understand this question.  There is no such 
thing as *the* interpretation of RDF.  The example given in 1.4 is 
*an* actual interpretation of an RDF vocabulary.

>If the former, then this should
>   be made clear. If the latter, then you perhaps could use
>   other variables, either for the first example or for
>   subsequent examples of the RDF MT itself.

Again Im not sure what you mean by 'other variables'. Is there a 
problem with using _:x for a nodeID in Ntriples?

>In section 2, paragraph 1:
>
>? You use the expression "{E}" but do not define the signficance
>   of the curley brackets. Is this a mathematical primitive to
>   be generally understood, or an omission?

It means the singleton set containing E. I  will add an explanatory note.

>Section 2.1:
>
>? Would the replacement of every rdf:ID value in an RDF/XML
>   instance to a 'uuid:' URI be an example of skolemization?

I don't think so.  Skolemisation would be rather tricky to do in 
RDF/XML because the blank nodes often have no direct lexical 
representation in XML.

>
>Sections 4 - 6:
>
>* In section 0.2 you imply that the term 'bNode' is obsoleted
>   but then use the term 'bNode' in the description of RDF and RDFS
>   closure rules. Should 'bNode' in these latter sections be changed
>   to 'blank node'?

Yes. Thanks.

>Section 6.1:
>
>* I understand "literal value" to equate to "lexical form", and
>   that an anonymous node can denote that lexical form, with
>   the actual representation of the form attached to the anonymous
>   node by a property, e.g. rdf:value.

That is one of the proposals. I devoutly hope that it is not adopted, 
but it is one of them. But even if it is adopted, the MT would treat 
that 'actual representation' as the literal, and the corresponding 
member of the value space as being the literal value.

>
>   Or by "literal value" do you mean the member of the value space
>   of some datatype?

Yes, that is what I meant. I will try to make this clearer.

>   If the latter, then don't we need some treatment of lexical datatypes,
>   value spaces, lexical spaces, and (presumably also) canonically
>   lexical spaces in the core MT?

Well, we need it eventually.  But in the meantime, the MT can just 
say that literals denote literal values (whatever those turn out to 
be).

The whole treatment of literals in the MT is a place-holder at 
present, as the document tries to make clear. We decided to put this 
version out because it had been waiting for so long for the 
datatyping discussions to be resolved, and I wouldnt want it to wait 
any longer just for that.

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:22:05 UTC