You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@clerezza.apache.org by "Henry Story (JIRA)" <ji...@apache.org> on 2011/07/07 07:37:16 UTC
[jira] [Created] (CLEREZZA-595) StringLiteral and PlainLiteral
semantics are wrong
StringLiteral and PlainLiteral semantics are wrong
--------------------------------------------------
Key: CLEREZZA-595
URL: https://issues.apache.org/jira/browse/CLEREZZA-595
Project: Clerezza
Issue Type: Bug
Reporter: Henry Story
The "Datatype Entailment Rules" in the RDF Semantics spec make it very clear that in rules xsd 1a and xsd 1b that the "a string"^^xsd:string is semantically equivalent to "a string"
<quote>
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("http://www.w3.org/2001/XMLSchema#string");
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: http://www.atlassian.com/software/jira
[jira] [Commented] (CLEREZZA-595) StringLiteral and PlainLiteral
semantics are wrong
Posted by "Reto Bachmann-Gmür (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLEREZZA-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061058#comment-13061058 ]
Reto Bachmann-Gmür commented on CLEREZZA-595:
---------------------------------------------
Clerezza doesn't do datatype entailment yet, not even where they are sanctioned by RDF-Semantics. Not sure if the equals method is the right place to do this. It would require changing the identity conditions in the Literal-interface. But I think it might be more consistent to just operate on the abstract syntax layer in rdf.core, also two Graphs are considered equals if they are isomorphic, mutual entailment isn't enough for Graph.equals to return true.
> StringLiteral and PlainLiteral semantics are wrong
> --------------------------------------------------
>
> Key: CLEREZZA-595
> URL: https://issues.apache.org/jira/browse/CLEREZZA-595
> 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="http://www.w3.org/TR/rdf-mt/">
> 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("http://www.w3.org/2001/XMLSchema#string");
> 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: http://www.atlassian.com/software/jira
[jira] [Updated] (CLEREZZA-595) StringLiteral and PlainLiteral
semantics are wrong
Posted by "Henry Story (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLEREZZA-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Henry Story updated CLEREZZA-595:
---------------------------------
Priority: Minor (was: Major)
moved the priority of this issue to minor. Code works as is with things as they are now, but it is worth tracking this issue and thinking about it over the longer term.
> StringLiteral and PlainLiteral semantics are wrong
> --------------------------------------------------
>
> Key: CLEREZZA-595
> URL: https://issues.apache.org/jira/browse/CLEREZZA-595
> Project: Clerezza
> Issue Type: Bug
> Reporter: Henry Story
> Priority: Minor
>
> 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="http://www.w3.org/TR/rdf-mt/">
> 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("http://www.w3.org/2001/XMLSchema#string");
> 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: http://www.atlassian.com/software/jira
[jira] [Updated] (CLEREZZA-595) StringLiteral and PlainLiteral
semantics are wrong
Posted by "Henry Story (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLEREZZA-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Henry Story updated CLEREZZA-595:
---------------------------------
Description:
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="http://www.w3.org/TR/rdf-mt/">
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("http://www.w3.org/2001/XMLSchema#string");
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);
}
was:
The "Datatype Entailment Rules" in the RDF Semantics spec make it very clear that in rules xsd 1a and xsd 1b that the "a string"^^xsd:string is semantically equivalent to "a string"
<quote>
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("http://www.w3.org/2001/XMLSchema#string");
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);
}
> StringLiteral and PlainLiteral semantics are wrong
> --------------------------------------------------
>
> Key: CLEREZZA-595
> URL: https://issues.apache.org/jira/browse/CLEREZZA-595
> 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="http://www.w3.org/TR/rdf-mt/">
> 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("http://www.w3.org/2001/XMLSchema#string");
> 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: http://www.atlassian.com/software/jira
[jira] [Commented] (CLEREZZA-595) StringLiteral and PlainLiteral
semantics are wrong
Posted by "Henry Story (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLEREZZA-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061551#comment-13061551 ]
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, here http://www.w3.org/TR/rdf-concepts/#section-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
xsd:float("0.5")=0.5
@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 xsd:String.
[1] http://www.w3.org/2011/rdf-wg/track/issues/12
"
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: https://issues.apache.org/jira/browse/CLEREZZA-595
> 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="http://www.w3.org/TR/rdf-mt/">
> 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("http://www.w3.org/2001/XMLSchema#string");
> 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: http://www.atlassian.com/software/jira
[jira] [Commented] (CLEREZZA-595) StringLiteral and PlainLiteral
semantics are wrong
Posted by "Henry Story (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLEREZZA-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061080#comment-13061080 ]
Henry Story commented on CLEREZZA-595:
--------------------------------------
This is not complex datatype entailment. This is the simplest of all datatype entailments. It reveals that there is a problem with the class distinction of PlainLiteral and TypedLiteral. The distinction is badly made. Plain Literal should not have a 1 argument constructor, but typed Literal should. If all "plain" literals are xsd:String then everything falls out correctly.
So really you need to rename PlainLiteral to LangLiteral, or something of the sort.
> StringLiteral and PlainLiteral semantics are wrong
> --------------------------------------------------
>
> Key: CLEREZZA-595
> URL: https://issues.apache.org/jira/browse/CLEREZZA-595
> 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="http://www.w3.org/TR/rdf-mt/">
> 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("http://www.w3.org/2001/XMLSchema#string");
> 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: http://www.atlassian.com/software/jira