W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > April 2002

Re: The place of rdfs:Literal's in the world...

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Mon, 29 Apr 2002 15:12:23 -0700
Message-Id: <p0510150ab8f36ac1e3e3@[]>
To: Patrick Stickler <patrick.stickler@nokia.com>
Cc: w3c-rdfcore-wg@w3.org
>On 2002-04-29 9:04, "ext Patrick Stickler" <patrick.stickler@nokia.com>
>>>>  .....
>>>>  # Rule 4 (this is new)
>>>>  {
>>>>     ?p rdfd:datatype ?d .
>>>>     ?s ?p ?l .
>>>>     ?l rdf:type rdfs:Literal
>>>>  }
>>>>  log:implies
>>>>  {
>>>>     ?s ?p ?o.
>>>>     ?o rdfd:lex ?l
>>>>  } .
>>>  I don't think rule 4 is valid. That is, Im not sure quite what
>>>  ?l rdf:type rdfs:Literal .
>>>  is intended to convey, but if its supposed to say that the object of
>>>  the previous triple is a literal, then the rule is not valid.
>I would like to (finally) clarify a few things about rdfs:Literal that
>have been confusing at least me (and perhaps others) for some time.
>A few specific questions:
>1. Is it true that rdfs:Literal rdfs:subClassOf rdfs:Resource ?

Not necessarily, no. That triple can be true or false in a given 
interpretation, ie its not true in all of them.

We could change the MT to make it universally true if y'all feel that 
would make sense. What that amounts to would be saying that all 
interpretations must have all literals in their universe of discourse 
(assuming that literals denote themselves, as they do no. If literals 
can denote values, as in the now-reopened datatyping proposals, then 
it would say that all interpretations must contain all literal 
values. )

>2. Even if a blank node or URIref denotes a (literal) string, can
>    a blank or URIref node be rdf:type rdfs:Literal?

Not sure what you mean.  Strictly speaking, a piece of the graph 
syntax doesn't have an rdf:type of any kind. The only *things* that 
are of rdf:type rdfs:Literal are strings; but a uriref can denote a 

>The latest Schema draft says:
>rdfs:Literal     This represents the set of atomic values,
                  eg. textual strings.
>rdfs:Literal represents the self-denoting nodes called the 'literals' in the
>RDF graph structure. Atomic values such as textual strings are examples of
>RDF literals.

Oh dear. It shouldn't say things like that. (Rats, something else to 
read and review. )

>Fair enough, but is a blank node that denotes a literal string
>"atomic"? What does it mean for a node to be "atomic"? And if a literal
>node is self-denoting, then I would expect that a blank node or URIref
>node that denotes a literal is *not* itself of rdf:type rdfs:Literal,
>since it is not a self-denoting node. Eh?

The thing that is of the type is the denotation of the node - what 
the node refers to, or talks about - not the node itself. So if the 
bnode denotes a string, then the triple made up of it plus 'rdf:type' 
plus 'rdfs:Literal' is true.  See the basic definition of I( s p o .) 
in the MT.

>It also says later:
>"values of rdfs:object can include both Literals and Resources."
>If literals are resources, why the conjunction? Why not just say values
>can be nodes or values can be resources? It seems to me that Literals
>and Resources are disjunct classes. Are they?
>My reading of both the original Schema spec and the latest drafts is
>that it is *not* the case that rdfs:Literal rdfs:subClassOf rdfs:Resource.

I agree with that, but...

>I.e., blank nodes and URIref nodes are never of rdf:type rdfs:Literal

.... not that, which is a different (and much stronger) assertion. 
That is, strictly speaking that seems meaningless to me, but I take 
it to mean that triples of the form

<ex:uriref> [rdf:type] [rdfs:Literal] .

are never true.(?) If that's what it means, I disagree. (And to make 
things come out so that this was always false, we would need to 
completely rewrite the entire MT from the ground up, since some 
triples would refer to the syntax itself and others would refer to 
the things mentioned by the syntax, and there would be no syntactic 
way to distinguish them. )

>as that is a special class that reflects members of the graph syntax. E.g
>URIRef/Blank Nodes       rdfs:Resource
>Literal Nodes            rdfs:Literal
>Property Arcs            rdf:Property
>Eh? Is this wrong?


>If so, why?

It confuses use and mention.

Suppose that we were to say that rdf:Property was indeed the class of 
property arcs, rather than the class of properties. Now, how would we 
assert that something was in this class? That would have to be a 
triple of the form

??? rdf:type rdfs:Property .

where ??? is a uriref or a bnode which *refers to* a property arc. 
How do you make a uriref refer to a property arc? You can't use the 
uriref which is on the property arc: it refers to the actual 
*property* , not to the arc. What else is there? (Ans: nothing.)

In general, there isnt any way in RDF to refer to an RDF graph's own 
syntax (other than reification, in a weak sense, and even that 
doesn't allow one to refer to the urirefs or arcs themselves, only to 
the triples.)

>So, it seems quite legitimate and correct, given the above definitions,
>for the closure rule in question to use rdfs:Literal to refer *only*
>to an actual literal (string) node and not to some blank or URIref
>node that may just happen to denote the same string resource.
>This suggests to me that my original closure rule is valid, and Pat's
>counter example may not be (?)

I think the counterexample works no matter how you interpret rdfs:Literal.

>*If* literals really are resources, then I'd like to see this explicitly
>defined as rdfs:Literal rdfs:subClassOf rdfs:Resource in the spec, so
>that this is clear.
>*If* literals are not members of rdfs:Resource, then I re-assert that
>the above closure rule is valid, and furthermore, that the earlier
>proposed use of rdfs:range to constrain a property to only the inline
>idiom via ?property rdfs:range rdfs:Literal is also valid, and the
>earlier proposed use of rdfs:range to constrain a property to the
>blank node idioms via ?property rdfs:range rdfs:Resource is also

I don't follow the reasoning path here, but the conclusions aren't 
supported by the current MT.

>I'd *really* appreciate some clarification on this issue. Thanks.

Hope this helps.


IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Tuesday, 30 April 2002 13:03:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:12 UTC