incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henry Story (JIRA)" <>
Subject [jira] [Commented] (CLEREZZA-595) StringLiteral and PlainLiteral semantics are wrong
Date Thu, 07 Jul 2011 20:06:17 GMT


Henry Story commented on CLEREZZA-595:

Let me make myself clearer.  I understand that if you base yourself on the Abstract Syntax
that they make there this slightly fishy distinction between typed literals and plain literals,

Those distinctions are basically purely syntactic distinctions. There is no semantic difference
between language and typed literals. Both are functions from strings to a literal value. The
URI of the typed literal is the name of the function in typed literal cases, and in the case
of the language literals the @ sign is just a shorthand for such a URL.  So in functional
notation we could write

xsd:int("2010") =2010
@en("an english sentence")="an english sentence"@en  = lambda s( s is @en of "an english sentence")

The syntax needs to make the distinction because some shortcuts were made syntactically to
benefit readers, and this is useful for parsers.

But as we agree there is not semantic distinction between "hello" and "hello"^^xsd:string.
xsd:string is what is known in category theory as the identity relation on strings. It relates
a string to itself.

Now you pointed out in an e-mail earlier on the list on 20th June

"It seems things has been discussed in the now closed RDF WG ISSUE-12 [1]. The resolution
seems to be to use "foo" as the preferred way (in concrete
syntaxes) to write "foo"^^xsd:String, but that the internal form should be "foo"^^xsd:String.
This seems to be consistent with Tsuy review of
CLEREZZA-304, the range of properties that have strings without language as value should be

So a simple solution would be to not have PlainLiteral(string: String) constructor. If for
syntactic reasons that were still needed, then one may well be better off having a factory
to create such objects.  fact.create("string") would create a TypedLiteral. a fact.create("string","en")
would create a LangLiteral .

I hope that claifies things.


> StringLiteral and PlainLiteral semantics are wrong
> --------------------------------------------------
>                 Key: CLEREZZA-595
>                 URL:
>             Project: Clerezza
>          Issue Type: Bug
>            Reporter: Henry Story
> The "Datatype Entailment Rules" in the RDF Semantics spec (section 7.4) make it very
clear that in rules xsd 1a and xsd 1b that the "a string"^^xsd:string is semantically equivalent
to "a string".
> The following two transformations rules are made explicit there
> <quote href="">
> xsd 1a:	uuu aaa "sss".      	             -->     uuu aaa "sss"^^xsd:string .
> xsd 1b:	uuu aaa "sss"^^xsd:string .	     -->     uuu aaa "sss".
> </quote>
> But if one creates a plain literal in Scala without a language tag one does not get the
equality as expected with the xsd:TypedLiteral equivalent.
> The following test will confirm this.
> 	@Test public void plainLiteralStringEquality() {
> 		String string = "a string is a sequence of characters";
> 		UriRef xsdstring = new UriRef("");
> 		PlainLiteral plainStringLiteral = new PlainLiteralImpl(string);
> 		TypedLiteral typedStringLiteral = new TypedLiteralImpl(string, xsdstring );
> 		Assert.assertEquals("an xsd:string is the same as the string itself, so it must be
the same as the plain literal",
> 				plainStringLiteral,typedStringLiteral);
> 	}

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message