W3C home > Mailing lists > Public > public-owl-wg@w3.org > May 2009

Re: abbreviations of string literals

From: Peter F.Patel-Schneider <pfps@research.bell-labs.com>
Date: Wed, 27 May 2009 15:23:07 -0400
Message-ID: <20090527.152307.234362379.pfps@research.bell-labs.com>
To: <alanruttenberg@gmail.com>
CC: <public-owl-wg@w3.org>
From: Alan Ruttenberg <alanruttenberg@gmail.com>
Subject: Re: abbreviations of string literals
Date: Wed, 27 May 2009 14:01:28 -0500

> On Wed, May 27, 2009 at 12:59 PM, Peter F.Patel-Schneider
> <pfps@research.bell-labs.com> wrote:
>> From: Alan Ruttenberg <alanruttenberg@gmail.com>
>> Subject: abbreviations of string literals
>> Date: Wed, 27 May 2009 08:51:37 -0500
>>
>>> In the Syntax document we have:
>>>
>>> "Literals of the form "abc"^^xsd:string and "abc@"^^rdf:text should be
>>> abbreviated to "abc" whenever possible."
>>>
>>> This seems to introduce a parsing ambiguity - when one encounters
>>> "abc" while parsing functional syntax, one doesn't know whether the
>>> structural specification should have a xsd:string literal or an
>>> rdf:text literal.
>>
>> Hmm.
>>
>>> In addition, this affects understandability of the reverse mapping.
>>> As I understand it, although the function syntax is used in describing
>>> the transformation, it is as notation for the corresponding structure.
>>> The reverse mapping description
>>>
>>> _:x rdf:type rdfs:Datatype .
>>> _:x owl:oneOf T(SEQ lt1 ... ltn) .
>>> { n ≥ 1 }
>>> ->
>>> DataOneOf( lt1 ... ltn )
>>>
>>> leaves literals unchanged in some sense. Suppose lt1 is a plain
>>> literal "abc". If we interpret this as an operation on structure, it
>>> can't be taken verbatim, as the structural specification only has
>>> typed literals. If we take this as a rewrite to functional syntax,
>>> then the expansion of "abc" is ambiguous, as described above.
>>
>> Hmm.
>>
>> This probably needs some attention.
>>
>>> -Alan
>>
>> peter
> 
> I think it can be addressed by
> 
> a) Saying the "abc" only abbreviates "abc"^^rdf:PlainLiteral in the
> syntax document. If you want xsd:[string] you need to use
  	 	      	           ^^^^^^^^
> "abc"^^xsd:string

This would work.

> and
> b) In the mapping document making explicit that plain literals in RDF
> correspond to rdf:PlainLiteral literals in the structural
> specification.

With the above change the mapping document does not need to be changed
to resolve this issuelet.  There would remain the "lexical" ambiguity,
but it would not be a structural ambiguity.

> Does this work? Is there a better way?

It's one way to go.

> -Alan

Note that the mapping document may need to be changed to effect the
revised document on the datatype formerly known as rdf:text, depending
on how the discussion on the datatype formerly known as rdf:text goes.
This change may eliminate the lexical ambiguity as well.

peter

PS: Yes, this is *very* nitpicky, but discussions of this sort do often
devolve to such nit-pickiness.
Received on Wednesday, 27 May 2009 19:24:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:42:12 UTC