Re: New draft of Semantics available.

On Fri, Mar 1, 2013 at 1:19 PM, Pat Hayes <phayes@ihmc.us> wrote:

> New edit of Semantics now posted which addresses issues noted below.
>
> Pat
>
>
> On Mar 1, 2013, at 1:05 PM, Peter Patel-Schneider wrote:
>
> > 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
> >
> >
>

[...]

>
> rdf:langString may end up having an L2V map

RIght. Im not sure how this will finally cash out, so lets leave it for
> now. I put in an issue note.
>
> >
> > "normatively" is no better than "conventionally"
>
> Really? Is there ANY wording that you would accept to say that this spec
> is intended to be consistent with any other specs that define datatype URIs?
>

No, and I think that this is consonant with the W3C requirements.  We could
put together a list of such specs, or even point to a list from elsewhere
(as long as that document had some longevity expectation), but simply
deferring to "any normative document", even if only from W3C, or even if
only those extant at some certain time, does not match what I expect from a
spec.  (I suppose that we could point to the list of current W3C specs and
say "all of those!", which I think would be technically acceptable, but I
don't think that we should do that either.)


>
> > but the following text is
> > fine, replace this sentence with
> > "D-interpretations MUST interpret any datatype IRI in Concepts Section 5
> as
> > described there."
>
> Yes, that is better. Done.
>

OK.



>
> What about rdf:plainLiteral? Do we recognize that as an 'official'
> datatype?
>
> >
> > if rdf:langString is given a trivial L2V, then "every other IRI" can be
> > simplified
>
> I don't see how. We still can't use the L2V mapping to define the
> interpretation of the literals, so there would still be an exception. It
> would work if we could give it the obvious L2V mapping on pairs, but we
> have agreed not to go there.
>

No, give rdf:langString a trivial mapping, so that "oiu@en"^^rdf:langString
is ill-typed, plus a value space of the appropriate pairs.  Then
rdf:langString is a normal datatype, and the only special thing in the
semantics is that language-tagged strings have a special mapping.

>
> >
> > It is not the case that a bigger D produces more entailments.  The
> datatypes
> > corresponding to the datatype IRIs might change.
>
> ? how?
>
> > In fact, it is possible
> > for a datatype IRI to denote different datatypes in different
> > interpretations during entailment.
>
> I don't understand what this means. Never mind datatypes, the denotation
> of any IRI does not change "during" entailment.
>

There is nothing in the semantics that says that interpretations must
assign the same element of the domain of discourse as the denotation of
every IRI, or even of every datatype IRI.   For example, there are simple
interpretations that map "2"^^xsd:integer into 2 and others that map it
into "2".  Similarly, there are {owl:real}-interpretations that map
owl:real into the datatype for xsd:string.  Of course, these
interpretations would not be allowed as OWL interpretations, but they are
perfectly fine outside of OWL.

I was thinking of the following situation:
- implementation 1 uses ex:number as integers
- implementation 2 uses ex:number as floating point numbers
Then the two versions of {ex:number}-entailment are incomparable, but only
the IRIs are considered in the "bigger", which invalidates the statement.



>
> >
> > If rdf:langString gets the right value space, then rdf-D-interpretation
> can
> > be simplified
>
> OK, yes indeed. I will fix this.
>
> >
> > 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)
>
> Huh? isnt "ss" a string? But I see what you are getting at, 27 could
> belong to I(xsd:string).
>

Oops, yes indeed.


> > , 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)"
>
> The difference would not be detectable in RDF. But maybe it would be
> clearer to do it this way, indeed.  OK, done.
>
> > although there is no mention that datatypes need a value space
> >
> > well-typed is not defined anywhere
>
> OK, fixed. That was a bad old edit.
>
> >
> > 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
>
> True. Let me think through this stuff a bit more carefully before making
> any more edits here. Ive put an issue note in.
>
> >
> > 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!
>
> But we can make it be so by fiat. I think we should. Any objections?
>
> Yes!  Under this change owl:real would not be a valid RDF datatype.


> >
> > the issue below is moot, as the entailment follows in RDF-{xsd:number}
>
> Yes, I realized that last night, and this is now in the RDF section (and
> debugged).
>
> >
> > 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}
>
> I had meant 'nnn' to represent any numeral, but it would be less confusing
> if I simply use 123 and people can generalize from that.
>
> > there is no xsd:number datatype
>
> Whoops. xsd:integer, of course.
>
> >
> > 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.
>
> Well, thats not legal RDF, so the example still works. But I take your
> point.
>
>
Yeah, hmm, you're right, but I think that the example might leave the wrong
impression.


> Pat
>

peter