Re: New draft of Semantics available.

Comments on Feb 28 version of RDF 1.1 Semantics


Issues to be fixed:
- make rdf:langString a regular datatype
  - unusual - empty L2V
  - only special casing is then interpretation of language-tagged strings
- elements of datatypes in RDF
  - better constraint
- add value spaces into datatype exposition


"s, p and o are in V," -> ""

"rules given above for names" -> "rules given above for ground graphs"

"1. the IRIs and literals ... refer to actual things"  doesn't make sense,
as IRIs always refer and is the number 3 an actual thing

"2. string literals ..." too early and doesn't make sense

"3. ... actual things" doesn't make sense, e.g., what about unicorns?

An RDF graph is true when
1. all literals in it refer to things
2. there is some way of interpreting the blank nodes in the scope as things
3. the IRIs in property position refer to properties, i.e., binary
relationships
4. and ...


rdf:langString may end up having an L2V map

"normatively" is no better than "conventionally" but the following text is
fine, replace this sentence with
"D-interpretations MUST interpret any datatype IRI in Concepts Section 5 as
described there."

if rdf:langString is given a trivial L2V, then "every other IRI" can be
simplified

It is not the case that a bigger D produces more entailments.  The datatypes
corresponding to the datatype IRIs might change.  In fact, it is possible
for a datatype IRI to denote different datatypes in different
interpretations during entailment.

If rdf:langString gets the right value space, then rdf-D-interpretation can
be simplified

The treatment of datatypes is strange in RDF.
The elements of the datatype are not closed off, so, for example, "ss" could
belong to I(xsd:string), correct would be
"for every IRI aaa in D, <vvv,I(aaa)> is in IEXT(I(rdf:type)) iff vvv is in
the value space of I(D)"
although there is no mention that datatypes need a value space

well-typed is not defined anywhere

IL(E) in LV for well-typed literals is redundant, because datatypes are
subclasses of rdfs:Literal

with the change above to fix datatypes in RDF, class extensions of datatypes
are not required to be constrained in RDFS

it is the case that the range of the L2V mapping for a datatype is in the
class extension of the datatype, but it is *not* the case that the two are
equal!

the issue below is moot, as the entailment follows in RDF-{xsd:number}

actually the issue is really moot, as "nnn"^^xsd:number is an ill-typed
literal and thus the entailment does not follow in RDFS-{xsd:number}

there is no xsd:number datatype

Not all triples of the form xxx rdf:type rdfs:Resource are true in all
interpretations!  "ss"^^xsd:integer rdf:type rdfs:Resource is not true in
any {xsd:integer}-interpretation.