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.  

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

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

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

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

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

so s has rdf:type of rdfs:Literal, 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.

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

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

> >14/ The RDFS schema-closure rule 1a has the effect of making all literal
> >     values be resources as all literal values have an rdf:type property
> >     because they are in the class extension of rdfs:Literal.  This is valid
> >     in the RDFS model theory, as all literals must be resources there
> 
> That is not my understanding.
> 
> >, but
> >     is probably not expected.
> 
> And it shouldn't be assumed to follow.  See comments on 8/

See my comments on point 8.

> >15/ The RDFS schema-closure rule 1c also has the effect of making most
> >     literal values be resources.
> 
> I fail to see why or how, since that rule explicitly excludes literals.

Sorry, I missed the restriction of uuu to non-literals.

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

> Pat

peter

Received on Wednesday, 26 September 2001 19:05:52 UTC