<s,l,x>-literals considered harmless

slx-literals have no impact (or at the most, minimal) on the model
theory and an axiomatic semantics.

MT: If there are any sentences that say "L is the set of strings" then
they need to be changed to "L is the set or literals" and a pointer to
Jeremy's definition will suffice.

AX: Guha claims that literals must be atoms. Well, that's true - but an
slx-literal is no more or less atomic than a string*. The important
characteristic is that an slx-literal is atomic (ie, indivisible) wrt
the axiomatic semantics.

That is, at no point in RDF does the language, or the string part of an
slx-literal get pulled away from the rest of the value and appear as
part of a new triple.

An objection might be that these literals are therefore useless, since
the non-assertional (templating) form of query cannot ask, "find me all
french words in the dictionary" by literal inspection/explosion.

The counter to this is that it cannot ask "find me all words containing
the substring 'gob' either". The fine-grained structure is ONLY visible
at the application layer.

I doubt that Pat or Guha have the inclination to axiomatise string
structure (it's a trivial but tedious pattern)** - nor is it necessary
to RDF for them to do so, since string manipulations can be left at the
application level.

If the "structure" of an SLX-literal _really_ must appear in AX (which I
don't believe) then literals simply become 3-tuples with standard
equality conditions (since the equality conditions of language tags mean
that a lang tag can be canonicalised by the "approved" representative of
its set of equivalents).

jan

* or "jan" isn't a substring of the lower-case lexical representation of
my name, goddarnit!

** however, along with log:implies, I believe cwm also has
str:substring, etc.

-- 
jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44(0)117 9287088 Fax +44 (0)117 9287112 RFC822 jan.grant@bris.ac.uk
I'm the dandy information superhighwayman.

Received on Wednesday, 19 June 2002 04:43:10 UTC