On 2010-06-30, Hugh Glaser wrote:
RDF permits anyone to say anything about anything . . . except a literal if it is the subject of the property you want to use for the description.
The way I see it, the main reason for this restriction is that the data is supposed to be machine processable. Literals rarely are, especially in their original, plain form. I mean, suppose we allowed literals as subject, predicate and object. What does it really mean if I say "Sally"@en "likes"@en "Mike"@en?
I'd argue pretty much nothing processable. That's because literals tack on an arbitrary, limited number of type specifiers (type and perhaps language) to textual data, and neglect everything beyond that. That is not how full disambiguation is done; it's how a human processor *minimally* disambiguates a piece of text, without making it unambiguous.
With Schema derived or otherwise strictly derived types, the level of disambiguation can be the same as or even better than with URI's, true. But then that goes the other way around, too: URI's could take the place of any such precise type. Beyond that, all that literals do is invite people to import more ambiguity into the RDF/SemWeb framework.
So, better to limit that to the object, in case we just *have* to have it somewhere. (I'd rather do without entirely.)
So I can say: foo:booth isNamed "David Booth" But of course I can't say: "David Booth" isNameOf foo:booth
You can say the same thing, as you pointed out. So you're aiming at grammatical symmetry in excess of expressive capability. Why? There is definite value in making the relation asymmetric: that way you can be surer that what is being talked about stays...the subject. It's not by any means sure that that is really going to be useful, no.
But at the same time it's perfectly sure that you would have to start employing triples with both the subject and the object a literal, before the current model can constrain you semantically. That'd then be pretty extreme: the precise semantics of literals are tricky enough as they stand. Pretty much the only genuine use cases I can come up with off-hand are explicit unit conversions and label translations -- and then anything that goes that far should probably get URI's and/or epi-RDF conversion code in the first place. After all, both scenarios also call for context, which might have to be disambiguated beyond mere lexical form and type. (E.g. homologues or units with identical dimensions but different usage.)
-- Sampo Syreeni, aka decoy - de...@iki.fi, http://decoy.iki.fi/front +358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
