RE: Literals (Re: model theory for RDF/S)

> >But that would really have to be defined as a more general rule than
> >just statments about specific instances of integers, otherwise, we'd
> >have to define an infinite number of statements to be sure they all
> >were known to any system trying to ask, is this resource "odd", etc.
> 
> No, you wouldn't, that's the point. If we can define classes of 
> literal values in terms of properties of the literals themselves, 
> then we have, potentially, a new way to determine membership in a 
> class. Right now, the only way to determine membership in anything in 
> RDF is to check to see if there are assertions in the graph which 
> entail an explicit assertion that the thing is a member of the class 
> (or container, etc.). But to find out if some literal is in 
> odd-integer, you don't even need to look at the RDF graph, you just 
> need to do divide it by 2 and see if theres a remainder. You can get 
> infinitely much assertional bang for your buck.

Right. I.e., we're not going to make a potentially
infinite set of statements like

  int:1 rdf:type foo:odd .
  int:3 rdf:type foo:odd .
  int:5 rdf:type foo:odd .
  ...

But rather capture the essence of "oddness" via a function just
as you describe.

But one would still like to know that a given literal value is 
an integer to be sure that the application of that function is
valid.

> 
> >I.e., rather than define explicit facts, we would define functions
> >from which we could infer the facts implicitly only as needed.
> >
> >>  ... If RDF had the ability to
> >>  assert properties of literals, the expressive power of 
> the language
> >>  would be quite radically increased.
> >
> >Well, I guess I'm not sure that that is the case with literals
> >given a URI representation -- as then the literals are no longer
> >literals but resources,
> 
> No, wait: they are resources, but they are still the values of 
> literals, and that is (well, might be) enough to give us a different 
> kind of handle on them.

I'm not sure I quite follow what you mean by "resources being the
values of literals" here. A property value (object) is either a 
literal or a resource, and if we say 'int:5' instead of "5" then
the value is a resource, not a literal.

Whether a given RDF based application applies some interpretation
to either representation is outside the scope of the MT, right?
In either case, they are just opaque logical constants -- though 
of different types.

So, if I choose to only use resource (URI) values in all of my
RDF graphs, even for typed data values that other folks might
represent as literals, I've not required any changes to the 
current MT semantics, right. A resource is a resource is a 
resource, and "no assumptions are made about the nature of 
resources". Right? So such a treatment would not require any
increase in the expressive power of the language.

> >so how does that actually increase the
> >expressive power of RDF, per se -- since the semantics of the
> >data typing is in the URI and RDF doesn't understand the semantics
> >of URI schemes...?
> 
> You keep assuming that literals have already been assimilated to 
> URIs, and I'm trying to point out that doing that loses something 
> important. Sure, once you've lost it, its not there.

I'm not making that assumption. Have literals if you like. I was
simply trying to clarify that if I use resources where otherwise
I might have used literals, and there exist no literals in any
of my graphs, then those portions of the MT concerning literals
are not relevant to my graphs (which have no literals).

Taking that a step further, if everyone used resources rather
than literals, then, logically, there would not be any need for
special treatment of literals in the MT. Right?

*** Disclaimer: I'm not proposing doing away with literals! Though
*** I'm perhaps using that as a way to explore the relation between
*** URI labled resources and literal "resources" in general.

What I'm not clear on is what you feel is being lost by using
a URI to represent a typed data value rather than a literal.
I.e., how does using an approach such as '#a #b int:5 .' lose 
anything in comparison to '#a #b "5" .' per se?  Does not the
URI form provide greater potential for defining or inferring
knowledge about the value?

Granted, in order to have "extra" knowledge about the actual
data type used, we need to either interpret the URI scheme (which
is outside the scope of the MT) or employ mechanisms such as
the (now unfortunately deprecated) rdf:aboutEachPrefix, e.g.

  <rdf:Description rdf:aboutEachPrefix="int:">
     <rdf:type rdf:resource="xsd:integer"/>
  </rdf:Description>

(apologies for the qname attribute value, tired of typing...)

> >And isn't it useful to keep very clear and distinct the "raw"
> >graph versus (possibly many) "cooked" interpretive layers above
> >that graph?
> 
> Yes, indeed, and the next draft of the MT document will make that 
> layering more explicit. My point was only that the exact dividing 
> line between the RDF layer and the RDFS layer seems somewhat 
> arbitrary (and some authors of the original specs seem to agree, by 
> the way.)  You could take just about any subset of the combined 
> RDF/RDFS vocabulary and make it into a coherent 'layer'.

Fair enough. Drawing lines between interelated levels is often
highly subjective and colored by context and greatest need.

Cheers,

Patrick

--
Patrick Stickler                      Phone:  +358 3 356 0209
Senior Research Scientist             Mobile: +358 50 483 9453
Nokia Research Center                 Fax:    +358 7180 35409
Visiokatu 1, 33720 Tampere, Finland   Email:  patrick.stickler@nokia.com

Received on Thursday, 4 October 2001 16:42:25 UTC