- From: Henry Story <henry.story@bblfish.net>
- Date: Sun, 20 Nov 2011 13:25:01 +0100
- To: Dominik Tomaszuk <ddooss@wp.pl>
- Cc: public-xg-webid@w3.org
On 20 Nov 2011, at 12:49, Dominik Tomaszuk wrote: > 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. Well that's why it's probably be better to go with xsd:hexBinary, because those problems have already been considered there, and it's the kind of thing people expect. Anyway as you see there is no ideal solution. My guess is that xsd:hexBinary will probably kill this discussion, make SPARQL queries a simple ASK query, and so make the implementations a lot more efficient for very large providers, and a lot simpler for startup implementors. Henry > > [1] http://www.w3.org/TR/rdf-plain-literal/ > > Domel Social Web Architect http://bblfish.net/
Received on Sunday, 20 November 2011 12:25:34 UTC