W3C home > Mailing lists > Public > public-xg-webid@w3.org > November 2011

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

From: bergi <bergi@axolotlfarm.org>
Date: Wed, 16 Nov 2011 22:57:19 +0100
Message-ID: <4EC431BF.7060901@axolotlfarm.org>
To: WebID Incubator Group WG <public-xg-webid@w3.org>
> Currently  we use the cert:hex datatype, which was especially
> invented to be easy to read for humans: it is possible nearly to copy
> and paste a hex from a certificate viewer or from openssl tools and
> get it right. It is extreemly lenient. But it is less standard than
> using the  xsd datatypes that are discussed in the RDF semantics
> document  http://www.w3.org/TR/rdf-mt/#dtype_interp
> 
> - xsd:base64Binary
> - xsd:hexBinary

-1

What the modulus really contains is an integer. The xsd:*Binary types
don't define how to convert the data. There are many different ways to
store integer values (big/little endian or even binary coded
decimal...). If we use one of *Binary types we must add a description of
their usage to the rsa:modulus property. I think that's not the idea of
data types - They should be self describing.


xsd:string

+1

With xsd:string everything is like it's now, except it's no longer
necessary to provide a data type in the RDF document and SPARQL query.
One could argue that the rsa:modulus property requires a description how
the contained data is coded, but in my opinion that's OK for a literal.
The ASK SPARQL query should also work with "FILTER regex()".
Received on Wednesday, 16 November 2011 21:57:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 16 November 2011 21:57:58 GMT