W3C home > Mailing lists > Public > semantic-web@w3.org > February 2010

how to define that a relation is a dataype?

From: Story Henry <henry.story@bblfish.net>
Date: Mon, 22 Feb 2010 01:15:47 +0100
Message-Id: <1877E0CE-6CEC-417F-A7C0-F1FA17282210@bblfish.net>
Cc: Dan Connolly <connolly@w3.org>, foaf-protocols@lists.foaf-project.org
To: Semantic Web <semantic-web@w3.org>
I have a relation :hex defined as

@prefix : <http://www.w3.org/ns/auth/cert#> .

:hex a owl:DatatypeProperty, 
    rdfs:label "hexadecimal"@en;
    rdfs:domain :Integer;
    rdfs:range :String;
    vs:term_status "unstable" .

This relates a number to 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" .

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 .

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 .

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. So it is clear from that the xsd:int is a relation from a number to a string.

So now, back to the original question: how do I write in my ontology that cert:hex is such a literal type?

:hex a owl:DatatypeProperty, 
    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 ? 
- what is the set of all strings? 

If xsd:integer is the set of all numbers, then how can it also be a map from numbers to strings?


[1] http://www.w3.org/TR/rdf-mt/#dtype_interp

Social Web Architect
Received on Monday, 22 February 2010 00:16:25 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:45:16 UTC