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

Thanks for making me look a bit more closely at the sparql11-entailment spec.

I think you are looking at the wrong part of the spec Dominik. You want to look at D-entailment

   http://www.w3.org/TR/sparql11-entailment/#DEntRegime

There you can see how all the integer types have built in entailment rules. 

"While the datatypes often have a single lexical representation for each data value (i.e., each value in the datatype's value space is denoted by a single representation in its lexical space), this is not always the case. A canonical mapping is a prescribed subset of the inverse of a lexical mapping, which is one-to-one and whose domain (where possible) is the entire range of the lexical mapping (the value space). Thus a canonical mapping selects one lexical representation for each value in the value space. The canonical representation of a value in the value space of a datatype is the lexical representation associated with that value by the datatype's canonical mapping."

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.

On the other hand perhaps with javascript we can just get the same effect in the browser now.

in which case I still would prefer xsd:hexBinary because it uses up less space than a decimal, and one could potentially get another 20% improvement with base64Binary .

Henry

On 20 Nov 2011, at 10:21, Dominik Tomaszuk wrote:

> On 19.11.2011 22:33, Dominik Tomaszuk wrote:
>> But I propose more readable and full-validate datatype based on
>> xsd:string and restrictions to hex and "-" sign:
> Better code:
> <rdfs:Datatype rdf:about="http://www.w3.org/ns/auth/cert#hex">
> <owl:onDatatype rdf:resource="http://www.w3.org/2001/XMLSchema#string" />
> <owl:withRestrictions>
>  <rdf:Description>
>   <rdf:first rdf:resource="http://www.w3.org/2001/XMLSchema#pattern" />
>    <rdf:rest>
>     <rdf:Description>
>      <rdf:first rdf:datatype="http://www.w3.org/2001/XMLSchema#string">[0-9a-fA-F]{2}(-[0-9a-fA-F]{2})*</rdf:first>
>      <rdf:rest rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil" />
>     </rdf:Description>
>    </rdf:rest>
>   </rdf:Description>
> </owl:withRestrictions>
> </rdfs:Datatype>
> And an example:
> rsa:modulus "00-cb-24...91-a1"^^cert:hex
> The advantage of this service is entailment [1].
> XSD string with restrictions -> XSD string -> simple literal so:
> SELECT ?v WHERE { ?v ?p "00-cb-24...91-a1" } may return query results.



> 
> [1] http://www.w3.org/TR/sparql11-entailment/
> 
> Best regards,
> Dominik 'domel' Tomaszuk

Social Web Architect
http://bblfish.net/