Re: New draft of Semantics available.

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
> 
> 
> "s, p and o are in V," -> ""

Whoops, fixed. 

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

fixed.

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

So, what is the problem? This is supposed to be an intuitive RE-statement of the semantic conditions for readers who are math-blind. IRIs can refer to literal values. 

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

Right, corrected now. This was leftover from when xsd:string was built into simple interpretations. 

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

Hey, if unicorns are in your universe of discourse, then they are actual things. 

But OK, strike "actual". Sigh.

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

OK

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

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

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. 

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

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

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

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

Pat

> 

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Friday, 1 March 2013 21:19:54 UTC