Re: model theory for RDF/S

>[Many portions of the previous exchange have been elided.]
>
>From: Pat Hayes <phayes@ai.uwf.edu>
>Subject: Re: model theory for RDF/S
>Date: Wed, 26 Sep 2001 16:23:50 -0500
>
>>  >1/ The document does not sufficiently pin down the relationship between
>>  >    literal values and resources.
>>  >
>>  >    The model theory does not require that literal values and resources be
>>  >    disjoint.
>>
>>  Right. It is deliberately agnostic on this issue.
>>
>>  >    I think that the document needs to come down firmly on one side or the
>>  >    other.
>>
>>  I disagree. The model theory does not depend on the resolution  of
>>  this debate, and will work unchanged in either case, so it is best
>>  left open.
>>
>>  I concede that the wording of the text could emphasize this point a
>>  little more clearly.
>>
>>  >Either it has to state that it is extending RDF to allow
>>  >    literals to be the subject of predicates, or it has to exclude the
>>  >    possibility of literals being the subject of predicates.
>>
>>  It is intended to conform to current RDF, where literals are not
>>  allowed to be subjects, but purely as a syntactic restriction. The
>>  model theory would apply to the more general case just as well. I
>>  think it is important to be clear when a restriction is not imposed
>>  by any semantic interpretation.
>
>There may however be problems when RDF is used as a basis for other
>formalisms.  I would much prefer to have a model theory that corresponds as
>closely to RDF as possible.

I believe that (in this respect) the MT does correspond to the 
intended meaning of RDF as closely as I know how to make it. One 
could draw an analogy with the (now abandoned, but...) restriction on 
subClassOf loops. In that case, you urged that the model theory not 
be made to fit the restriction 'tightly', but that the restriction be 
thought of simply as a syntactic restriction which was motivated by 
non-semantic considerations. I feel the same way about this issue. 
There is no *semantic* justification for excluding literals from 
subject position: the meaning of such a triple is perfectly clear and 
unambiguous. Nevertheless, they are excluded, presumably for some 
other reason. The current framework does not provide any obstacles to 
someone in the future changing RDF's mind on this point. Since model 
theories seem to be regarded by many language developers with a kind 
of religious awe, it seems to be generally a useful strategy to keep 
them as free from unnecessary encumbrances as possible.

>The question is whether you are doing something for RDF or something for
>the semantic web.  I would prefer the latter.

Well, argue that point with the W3C. The WG charter is to fix up RDF, 
not to re-define it. Its a subtle point, but one that the group takes 
seriously as a guide to its decision-making. (However, see my later 
confession about un-asserted triples.)

>You may argue that being agnostic in the model theory for RDF is better if
>the goal is to do something for the semantic web.  I disagree.  (However,
>this is probably getting too far afield from the current technical points.)

Yes, I would argue that, in fact; but agree about the further afield.

>
>>  >2/ The model theory does not assign meaning to RDF graphs.  Instead it
>>  >    assigns meaning to RDF graphs with an extra, nowhere-defined attribute
>>  >    on edges.  If this is supposed to be a model theory, then it should be
>>  >    rigorous, and not have any undefined junk floating around.
>>
>>  I do not follow this point. What attribute on edges?
>
>The ``asserted'' attribute.

Ah, I see. Well, just ignore it, if it makes you feel uncomfortable. 
It plays no role in current RDF since all triples are asserted. 
However, this is the one place where I *was* thinking of the semantic 
web rather than just about RDF (and you are the only person to have 
complained about it, which is rather ironical.)

Let me fess up here. As you know, there has been a lot of discussion 
about how to extend RDF to more expressive languages and notations, 
and the relative carelessness about use/mention distinctions which 
has been typical of the RDF metatheory has caused a lot of 
complications, and led to some very baroque and unworkable (IMHO) 
suggestions. I am certain that there is a simple, easy way out of all 
this mess, if we were just to extend RDF (and it would be a real 
extension, I concede, but a very small one) to allow this 
asserted/not-asserted distinction, thereby allowing more complex 
expressions of more complex languages to be encoded in the RDF data 
model (ie as sets of triples) without thereby being automatically 
asserted. Putting this in the MT document was a sneaky way of making 
the easy solution to this problem easier to do in the future, by 
pointing out that having un-asserted triples in an RDF graph does not 
cause everything to immediately break, as long as they can be somehow 
distinguished from the asserted ones (by some mechanism not here 
specified, and perhaps one that lies outside of RDF itself). How a 
parser is to know which triples are asserted and which not (in case 
some are not) is another matter, and would require changing the 
syntax of an RDF graph in some way, eg by adding 'contexts' as in N3, 
or by invoking some special property of reified triples, as some 
people have suggested, or by using quads instead of triples, or 
putting the non-asserted triples into a separate file, or whatever. 
But, my implicit point is here, we can still call the result RDF, 
maybe with a prime added, and still send it along RDF pipelines and 
have it processed by RDF engines, and so on, just as long as we can 
somehow make this distinction.

>
>>  >4/ The model theory breaks down for edges whose edge label does not map
>>  >    into a property as IEXT is only defined on properties.
>>
>>  It doesn't break down; it assigns false to any such triple, by the
>>  third rule in 1.3
>
>Not so.  If IEXT(I(p)) is not defined, then you cannot determine membership
>in it so you can't determine I(s p o.).

No, I insist. The rule says that I(s p o.) is true if some condition 
holds involving IEXT(I(p)), otherwise false. IF IEXT(I(p)) is 
undefined, then the condition does not hold, and so the triple is 
false. (The language of the *metatheory* is not weak three-valued 
logic.)  I will add a brief note emphasizing this point to make it 
clear.

>
>>  >7/ The mapping of unlabeled nodes is to the ``domain'' of interpretations,
>>  >    but interpretations don't have domains.
>>
>>  IR is defined to be the "domain or universe of the interpretation"
>  > (section 1.3).  This usage is common in model theory, but to avoid
>  > confusion I will change the terminology in the next version.
>
>Oops, I missed this.  I was thinking that there were two possibilities,
>namely IR and IR u LV.
>
>>  >8/ In the model theory for RDFS, there is the requirement that all literals
>>  >    have rdf:type of LITERAL.
>>
>>  I hope not. I was careful to not include that case. I think you will
>>  find that the RDFS rule table makes no mention of literals other than
>>  to exclude them from some cases.....
>
>Consider the following from Section 4 of your model theory document:
>
>	ICEXT(I(rdfs:Literal)) = LV
>
>	<x,y> is in IEXT(I(rdf:type)) iff x is in ICEXT(y)
>
>for any s a literal we have
>
>         I(s) = XL(s), from Section 1.3
>
>so
>
>	I(s) is in LV since the range of XL is LV, from Section 1.2
>
>so
>
>         I(s) is in IEXT(I(rdfs:Literal))
>
>so
>
>	<I(s),I(rdfs:Literal)> is in IEXT(I(rdf:type))

All OK so far; but I note that so far this has all been about literal *values*.

>so s has rdf:type of rdfs:Literal,

No. Well, its not quite clear what that means. It does not mean that the triple

s rdf:type rdfs:Literal .

is true in the model theory, since that triple isn't wellformed in 
RDF, so it never gets assigned a truthvalue by the model theory. If 
it were in the language it would be true, I agree; but it isn't, so 
the question does not arise.

>so its interpretation is in the subject
>position of a property, which makes literal values be resources as only
>resources can be in the subject position of properties.

That last observation is a purely syntactic one, and your argument to 
that point has been purely semantic.  Properties may hold of things 
which are denoted by literals, without that requiring that the 
literals can occur in subject position. The proper conclusion is that 
there are some truths that simply cannot be said in RDF; which might 
indeed be a reasonable criticism of RDF, but it doesn't make the 
model theory incoherent.

>
>>  >9/ The model theory for RDFS is missing the requirement that the vocabulary
>>  >    contain all the RDFS ``pre-defined'' URIs.
>>
>>  Right. That seemed to not be a model-theoretic matter, to me. The MT
>>  assigns meanings to the triples it finds, but does not impose any
>>  requirements on what triples must be present. But on reflection, it
>>  maybe would be more coherent, and ultimately simpler, to insist that
>>  they be included.
>
>But RDFS has a base theory which I think should be in all models, so we get
>to the same conclusion, perhaps via different rationales.

Yes, I have come to agree with you, and will rewrite that section to 
reflect this. (However, the other members of the WG will need to 
approve this change before it can become part of the WP, of course.)

>
>>  >12/ The RDFS conditions are missing the range restriction on rdf:type.
>>  >     Without this restriction, ICEXT is not simply a convenience nor is
>>  >     rdfs:Resource an rdfs:Class in the model theory.
>>
>>  Whoops. This?
>>
>>  rdf:type rdf:range rdfs:Class .
>>
>>  Indeed, there seems to be no way to generate that, which should of
>>  course be in every closure. Damn, you are right. And of course also:
>>
>>  rdfs:subClassOf rdf:range rdfs:Class .
>>  rdfs:subClassOf rdf:domain rdfs:Class .
>  > rdf:range rdf:domain rdfs:Property .
>>  rdf:range rdf:range rdfs:Class .
>>  rdf:domain rdf:domain rdfs:Property .
>>  rdf:domain rdf:range rdfs:Class .
>>
>>  This would then simplify the table, since rule 9 would follow from 5
>>  and 6. (Some of these may be derivable from others, I havn't checked
>>  in detail. Dont think so, though.)
>>
>>  However, I think that is all that we need. Do you see any others
>>  (bearing in mind that we are ignoring the class rdfs:Literal as
>>  unusable) ?
>
>I don't know.  Further, I don't think that you can just take the RDFS
>document and assume that it is correct.  You will have to slog through the
>proof of the Schema Lemma to see if you have got everything, at least.

I know.  I just wondered if you could see anything obviously missing.

>....
>>  >17/ Because of the complexity of RDFS, I won't believe the Schema Lemma
>>  >     until I see a completely worked out proof.
>>
>>  Fair enough. I no longer believe it myself. What I am sure of is that
>>  there is *some* closure table for which it is correct, however. Also,
>>  it should be stated so as to explicitly rule out the rdfs:Literal
>>  class.
>
>Probably.  However there might not be a finite schema-closure for full RDF!

There must be, since the Herbrand universes are always finite. Until 
one can build functional terms recursively, any set of generation or 
closure rules is just going to do combinatorics on the finite set of 
possible triples.

Pat

-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Thursday, 27 September 2001 14:04:11 UTC