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.

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...

--

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.

  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.

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? 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.

  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 ;-)

  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.

In section 1.5:

? Does your example "_:x a b . c b _:x ." extend from your
  "a b c" example in 1.4? Or does it relate to the actual
  interpretation of RDF? 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.

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?

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?
 
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'?

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.

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

  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?

(review of the Appendices omitted ;-)

Regards,

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Friday, 18 January 2002 04:32:43 UTC