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

 

The model theory doesn't assume that. Two different URIs can denote the same
resource (see  http://www.w3.org/TR/rdf-mt/#example1 ). However I think that
your point here (and throughout) does not really depend on this assumption.
The point is that two different URIs *could* refer to different resources in
*some* interpretation. They are not forced to co-refer. That is all you need
to make your point, I think.
 

 
Yes. Thanks. That does it for me. ;-)
 


Insofar as as a generalized, consistent, global representation
for a given data type, though, one would expect that there would
be constraints defined which prohibit semantically vacuous variant
forms, such as above. So yes, you bring up a very valid requirement
for e.g. an int: scheme, that we wouldn't get int:00000000005, etc.
but that's an issue for the particular scheme, not the methdology of
URI encoded literals itself, I think (apart from specifying it as
an expected quality of every such scheme to not have semanticly
vacuous variant forms).


That seems to me a bit like saying that People Should be Good counts as a
moral code. It may be unreasonable to require all schemes to be unique in
this way (eg leading zero suppression may be essential in some schemes
designed to support arithmetic, or consistency with programming language
conventions); and even if we do, what is to prevent there being two
different schemes for the same set of values, eg two different notational
schemes for the natural numbers?

 Agreed. RDF could not require it, but those URI schemes that achieve that
ideal (or at least define
 the expectation of achieving that ideal) would likely be preferable to
other schemes as they alleviate
the need for higher levels of logic equating semantically vacuous forms.
 

encoded literals to act as the subject of statements,



But there would be no way to prevent it, and so the semantics would need to
support it.

 

Agreed. Yet the semantics already supports it, if "literals" are encoded by
URI, eh?   ;-)
 
Cheers,
 
Patrick