Review of MT

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Fri, 18 Jan 2002 11:33:34 +0200
To: RDF Core <w3c-rdfcore-wg@w3.org>
Message-ID: <B86DB88E.BCDC%patrick.stickler@nokia.com>
```

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

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

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:54 UTC