Re: WebID-ISSUE-61 (xsd): xsd datatypes [ontologies]

On 20.11.2011 10:54, Henry Story wrote:
>
> In your example below you are putting syntactic restrictions on how the
> datatype should be written out. But that does not give us the semantic
> mapping we need. So unless the only way to write out the hex strings is
> with 2 characters followed by a '-' with no initial and final white
> space, and no way of entering new-lines, then you won't have a canonical
> representation. If you don't have a canonical representation then you
> have to specify a map to a canonical one. cert:hex does just that: it
> says remove any non hex characters. That is what gives it the
> flexibility of being useable in the wild with people cutting and pasting
> information from their browser. It is also what allows us to make easy
> to explain videos of how the key in the browser relates to key in the page.
>
> If you don't think that is needed then one might as well go with well
> known datatypes. xsd:hexBinary is already defined and it has the
> advantage of even having another xsd:base64Binary way of writing things
> out. xsd:integer has the advantage of being mathematically the simplest.
>
> It's just a pitty they did not make more flexible hex datatypes when it
> would have been so easy to do that.
OK, but my point of view is machines like. OK you can write:
rsa:modulus "SSBsaWtlIFdlYklELg=="^^base64Binary
But is it valid modulus? No, it isn't.
You can write:
rsa:modulus "12:34..."^^xsd:string
or mayby rsa:modulus "12-34..."^^xsd:string
How to parse it? It is not possible to consider all cases.
Some people vote for xsd:string (without restrictions). It has some 
benefits but also allows to write:
rsa:modulus "I like WebID"^^xsd:string
Moreover why xsd:string, and why not RDF literal, or PlainLiteral [1]?
Semantic view is important but don't forget about abstract syntax.

[1] http://www.w3.org/TR/rdf-plain-literal/

Domel

Received on Sunday, 20 November 2011 11:49:43 UTC