- From: Pat Hayes <phayes@ihmc.us>
- Date: Sun, 21 Feb 2010 23:57:54 -0600
- To: Story Henry <henry.story@bblfish.net>
- Cc: Semantic Web <semantic-web@w3.org>, Dan Connolly <connolly@w3.org>, foaf-protocols@lists.foaf-project.org

On Feb 21, 2010, at 6:15 PM, Story Henry wrote: > I have a relation :hex defined as > > @prefix : <http://www.w3.org/ns/auth/cert#> . > > :hex a owl:DatatypeProperty, > owl:InverseFunctionalProperty; > rdfs:label "hexadecimal"@en; > rdfs:domain :Integer; > rdfs:range :String; > vs:term_status "unstable" . > > This relates a number to a string. Fair enough. But be clear: that is *not* a datatype. It is the inverse of a datatype mapping, in fact. Datatypes always map FROM strings TO values. They are a way of having a fixed interpretation mapping for a string. > The reason we don't want to use the xsd: relations exclusively, as a > method of relating a number to string are numerous: > 1. people may want to copy and paste their public key from an > OpenssL program where these are often in hexadecimals and have > colons or spaces in them > 2. xsd:integer is in decimal notation, which is too verbose > 3. we would like to allow people to also use base64 notation later > if they feel like it, to reduce the space this information takes > 4. people will be publishing these keys on their home pages, so it > will be nice to allow them as much freedom to make them friendly by > shaping them in the form of a heart, or putting unicode hearts in > them. > > Anyway, we have our reasons... > > Now, consider the number 1234 which is bigger than 1000 and smaller > than 2000 and the character string "1234" which is 4 characters > long. Notice that 1234 in hexadecimal is "4D2" and in binary > "11010010", so the same number can have different representations, > or string literals to describe it. One could write the relation > between the number and the ways of writing it in n3 like this: > > 1234 :base64 "TU"; > :hex "4D2"; > :dec "1234"; > :oct "2322"; > :bin "11010010" . You could, but by using properties from values to strings, you have kind of shot yourself in the foot. > > According to the RDF Semantics document [1] > > [[ > Formally, a datatype d is defined by three items: > > 1. a non-empty set of character strings called the lexical space of d; > 2. a non-empty set called the value space of d; > 3. a mapping from the lexical space of d to the value space of d, > called the lexical-to-value mapping of d. > ]] > > So a datatype is indeed defined as being a mapping (a relation) from > string to number, which is good! Except that we seem to want one > from number to string. But it is clear that this is indeed what it > has to be, from the following reasoning. Consider the graph: > > :x :dollarValue "1234"^^xsd:int . > > if this WERE equivalent to the two relations: > > :x :dollarValue "1234". > "1234" xsd:int 1234 . No, its certainly not. The literal denotes the value, not the string. So the right way to split that up into two triples would be :x :dollarValue :y . "1234" xsd:int :y . where :y is the literal value, ie in this case, the integer one thousand two hundred and thirty four. Not a string. You could use a bnode for :y, of course. > > then since it is also true that > > "1234" xsd:int 1234 ; > is :oct of 668; > is :hex of 4660 . > > ("is rel of" is just an n3 way of writing an inverse of a relation) > we can merge the two graphs and have: > > :x :dollarValue "1234". > "1234" xsd:int 1234 ; > is :oct of 668; > is :hex of 4660 . > > And now it is clear that the :dollarValue relationship as written > above is not going to help us decide which of the relations leaving > "1234" is the one we need to choose: there can in fact be an > infinite number of them. So we still don't know the dollar value > of :x . BUt if you do it, er, correctly, then you will find it works. There is only one value being talked about here. Let me use xhex, xoct, etc. for the inverses of your hex, oct, etc - ie the datatype mappings from strings to values, not values to strings - then you have :x :dollarvalue :y . "i234" xsd:int :y . "4D2" :xhex :y . "2322" :xoct :y . etc. > > IE it is clear that the :dollarValue and any relation from something > to a number, has to be a relation to a number, and not to a string > representation of that number. Right, but... > So it is clear from that the xsd:int is a relation from a number to > a string. On the contrary, its clear that it is exactly the other way round :-). See above. Less contentiously, it all depends on which way you write the triples. Do it this way, everything works out as it should. > > So now, back to the original question: how do I write in my ontology > that cert:hex is such a literal type? Well, if you used the cert:xhex form, you can just say cert:xhex rdf:type rdfs:Datatype . > > :hex a owl:DatatypeProperty, > owl:InverseFunctionalProperty; > rdfs:label "hexadecimal"@en; > rdfs:domain :Integer; > rdfs:range :String; > vs:term_status "unstable" . > > There are a number of other questions. > > - What is the set of all numbers? is it xsd:integer ? Yes, a datatype name can be used as the class of all the datatype values. > - what is the set of all strings? xsd:string Though you should say 'class of..' > > If xsd:integer is the set of all numbers, then how can it also be a > map from numbers to strings? In RDFS, the same name can be used to mean a mapping and a class and an individual. Same is true in OWL 2 and ISO Common Logic. Saves a lot of name-inventing. We used this in the datatyping. Used as an individual, the dtype name means the actual datatype as a thing, so we can say that "it" is a datatype for example. Used as a class name, its the class of all the values. Used as a property, it is the string-to- value mapping. Pat Hayes > > Henry > > > [1] http://www.w3.org/TR/rdf-mt/#dtype_interp > > Social Web Architect > http://bblfish.net/ > > > ------------------------------------------------------------ IHMC (850)434 8903 or (650)494 3973 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes

Received on Monday, 22 February 2010 05:58:59 UTC