Re: abbreviations of string literals

2009/5/27 Alan Ruttenberg <alanruttenberg@gmail.com>:
> 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.

My understanding was that all of "abc"^^xsd:string "abc@"^^rdf:text
and "abc" (without type) are structurally equivalent and that the
sentence you've quoted asserts a preference for the final form.  Thus,
a typed string literal (either rdf:text or xs:string) should never
exist in the functional syntax or in RDF produced by the forward
mapping.

> 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.

As above, my interpretation is different.  I thought the reverse
mapping would use the abbreviation and the literal would be "abc"
untyped if it went through a RDF -> FS -> RDF round trip.

Given that we've read the same text and interpreted it differently,
I'd appreciate if the authors could clarify the intention and perhaps
clarify the Syntax doc (sec 5.7).

Thanks,
-- 
Mike Smith

Clark & Parsia

Received on Wednesday, 27 May 2009 16:58:19 UTC