Re: (very) first draft of semantics available

On Feb 20, 2013, at 1:45 PM, Peter Patel-Schneider wrote:

> My comments and suggestions:

Thanks, these are really useful. 

> 
> 
> Required for FWD:
> 
> Remove loaded words (irrational, idiot's, ...)

Awww, you are no fun. 

> 
> Fix datatypes
> 
> 
> 
> 
> Externally-visible changes to the semantics:
> 
> 1/ Ill-typed literals do not denote.  This changes the satsifiability status
> of some graphs with ill-typed literals.  For example
>   ex:John ex:age "57.0"^^xsd:integer . 
> is now unsatisfiable in any RDF interpretation with xsd:integer as a
> datatype.

True. This behavior was requested by Richard Cyganiak, and it seems to make sense. 

> 
> 2/ LV is no longer used.  OWL uses LV from RDF, and so would have a dangling
> pointer.

LV is still *defined* to be the set of all values of actual literals in the universe. Its just not part of the basic structure. This should not change anything for OWL. 

> 
> 3/ Literal values need not be in the domain of discourse.

?? They should be. Perhaps this is a slip, which I will correct. 

> 
> 
> Issues:
> 
> 1/ Which interpretations can be used in entailment?

Um, all interpretations? That is, xxx-entailment means truth is preserved by all xxx-interpretations. 

> There are no problems with using partial interpretations in RDF per se, I
> think, but consider 
>   "24"^^xsd:integer rdf:type xsd:integer .
> under {xsd:integer}-RDF-interpretations.  Is this true in all such
> interpretations? 

Right now, no, because the constraints on classes involving rdf:type are not introduced until we define RDFS. We could change this. Frankly I don't think it really matters, as we could define entailment regimes for just about any combination of the rdf: and/or rdfs: vocabularies and/or datatyping. 

It does seem natural since rdf:type is in the rdf namespace, I agree.

> If not, then how does this work for entailment?
> 
> 2/ The empty graph is not true in all simple interpretations. 

Seems to me it is. Simple interpretation conditions say the only way a graph can be false is by having a false triple, so empty must be true, no? 

> Does this
> matter?

It would, yes. 

> 
> 3/ Are rdf:XMLLiteral and rdf:HTML required for RDF interpretations?

No. We could change this, if you think it would be better if they were. Again, perhaps they should be since these are in the rdf: namespace.

> 
> 
> Technical Suggestions
> 
> 1/ Move xsd:string and rdf:LTL into D-entailment. 

Concepts describes these two as "built in". So RDF without these two types for literals is not really defined; and they correspond to plain literals in 2004 RDF, which were covered by simple entailment back then, which is why I put them here. But maybe you are right. 

> Even if this doesn't
> happen, there is no need to treat xsd:string or rdf:langString specially in
> simple entailment.  Then there would be no need to have any special
> datatypes, proceeding as follows:
> - a datatype is a mapping from either strings or strings and language pairs
>      into a value space
>   - for example, xsd:string, xsd:integer, rdf:langString
> - a D-intepretation is respect to a set of pairs of names and datatypes,
>   i.e., its set of datatype associations
> - all datatype associations must be compatible with XML Schema Datatypes
> - all datatype associations must include rdf:langString and xsd:string and ???
> - RDF interpretations might have just these datatypes or might also have
>   others 
> Currently there is no need that a datatype for xsd:string has an L2V that
> maps strings into themselves.  Such a datatype is, of course, rather
> useless, but nonetheless permisssable.
> This would also fix the "effectively recognized" business, as well.

True. I went back and forth on this. I think it might work out better the way you describe. 

It does rather bother me that we are going to have entailments like 

aaa ppp "sss"^^xsd:string .
|=
aaa ppp _:xxx .
_:xxx rdf:type xsd:string .

in simple entailment. 


> 2/ Bad languages tags are invalid syntax and cannot occur in RDF graphs.

OK, good, thanks.

> 
> 3/ Fixes for datatypes
> - RDF - if v is in the value set of D then <v,D> in IEXT(I(rdf:type))
> NOTE:  This makes the domain of discourse for all D-interpretations infinite.

Does this bother you? We could keep D-interpretations finite by only requiring this condition for values denoted by a literal in the vocabulary. 

I find myself pulled to conflicting directions over this (and related) issues. On the one hand, the simplest way to state a lot of these conditons is to state them for *all* values (as here) and similarly to say that all interpretations are mappings from *all* IRIs, and so on. This avoids a host of verbiage and fussing over exact domains of mappings, and qualifications about being in the vocabulary and so on, none of which is really germane and just clutters up the exposition for the average reader. But on the other hand, this forces things to be infinite that could in fact be finite and everything still work, and this finiteness is important for another class of reader. I would hope that this other class of reader, competent in model theory, would find it obvious that all of this can be restricted to much smaller structures which are defined only on the vocabulary actually in use in any given case, and that these can be finite. Can we rely on this, do you think? Or are people going to say that since the simple statement is labelled 'normative', that RDF structures are *required* to be infinite? 

My inclination is to use the simple presentation in the body of the text, but have notes linked to an appendix which explains the restriction-to-actual-vocabulary variation and why it allows for finite interpretation structures. 

Comments on this idea? 


> - RDFS - if D is a datatype then <D,I(rdfs:Datatype)> in IEXT(I(rdf:type))
> 
> Technical wording changes:
> 
> 1/ Rewrites for partial interpretations, including:
> - simple semantic mapping for literals is partial
> - simple semantic mapping for a triple is false if any literal in it does
> not denote

We have both of these now, no?

> - do all IRIs denote? 

Yes.

> If so there are lots of places where the wording
> indicates that they might not. 

The basic rules require that the IR mapping is total. Does that not cover it?

> If not, then this should be made clear how
> they might not.
> 
> 
> Other Suggestions
> 
> 1/ Remove philosophical stuff that could go into the idiot's guide. 

Agreed. I am now drafting the idio..., er, beginner's guide as a separate note which will get patched back in as an appendix later. 

> 
> 
> 2/ All simple interpretations used to be finite, so the note about
> finiteness of D-interpretations is a bit awkward.

I am assuming as an editorial stance that this document should not presume that one has read the 2004 specs first, so might need to (re)state things which have been obvious in the past. 
> 
> 3/ Remove note on infinity of RDF interpretations and subsequent discussion.

OK. 

> 
> 4/ Move discouraged stuff to an appendix and label it as historical, or
> simply remove it.

Yes. 
> 
> 5/ Remove stuff about OOP.

I want this in there somewhere, as this has given rise to a lot of confusion in the past. (And still does, in fact.) Maybe in the beginner's guide. 

> 6/ Remove note on inference rules, which even uses a particular meaning for
> "inference rule".

Hmm. What do you feel about restating all these conditions as rules (strike "inference") ? It could be done and a lot of readers would find it easier to follow. 

> 
> 
> 
> Other Wording changes:
> 
> 1/ Initial note saying that this document depends on the new version of
> CONCEPTS, which is not yet written, but that there should be no surprises.

> 
> 2/ Hyperlink defined terms back to their definitions

Yes, a lot of this needs doing. I want to get the text more or less stable first, though. 

> , either in Concepts or
> Semantics, e.g.  
> - name
> - vocabulary
> - ground RDF graph
> - ill-typed (particularly important as this is a forward reference)
> - lean graph
> - ...
> 
> 3/ It is unfortunate that vocabulary is used in two senses: a) the domain of
> IS, and b) vocabulary interpretations.

Yes. I have a thought to try out on you, which is to eliminate the first sense of vocabulary altogether, and say that all interpretations are defined on *all* IRIs. So the whole concept of an interpretation *of a vocabulary* is simplified to not speak of vocabularies. The entire Web, past present and future, is one giant vocabulary (or, if you prefer, one giant FO language.) Of course they are all then infinite, but (as will be pointed out in a technical note) the actual interpretation structure, including the universe, can still be finite, and it is only necessary to define the interpretation mapping for the IRIs (and literals) which are actually in use. 

Comments on this idea? Seems to me it will make life easier for the folk who are struggling with model theory in the first place, and will be an obvious hack for those who are familiar with the basic ideas and might be concerned about finiteness. The whole "of a vocabulary V" business does not really play any useful role in the 2004 specs. And this would bypass a whole pointless discussion about the infinitude of the rdf:_n container vocabulary, for example. 

> 
> 
> Typos:

Thanks, will fix. Im sure it is full of typos, in fact. 

Pat

> 
> 1/ *IL* was not a partial mapping
> 
> 2/ rules given above XXXXXfor namesXXXXX
> 

------------------------------------------------------------
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 Thursday, 21 February 2013 02:11:43 UTC