- From: Story Henry <henry.story@bblfish.net>
- Date: Mon, 22 Feb 2010 10:47:18 +0100
- To: Pat Hayes <phayes@ihmc.us>
- Cc: Semantic Web <semantic-web@w3.org>, Dan Connolly <connolly@w3.org>, foaf-protocols@lists.foaf-project.org
On 22 Feb 2010, at 06:57, Pat Hayes wrote: > > 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. Ah! If I told you that I thought so, you would not believe me. So luckily I can point to an irc log :-) http://chatlogs.planetrdf.com/swig/2010-02-21.html#T19-33-52 > [snip] >> >> :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. > [snip] >> 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. Great. Thanks for helping me clarify this. >> >> 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 . ok so @prefix <http://www.w3.org/ns/auth/cert#> cert:easyHex rdf:type rdfs:Datatype; owl:inverseOf cert:hex; rdfs:range :Integer; >> >> :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..' I thought that: - a property is a set of ordered pairs - a type is a set of things >> 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. But all of these names are URIs, so they can only refer to one thing right? Are you saying it is a weird union object of all these things in rdfs? Let me expand on this in what follows... > 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 xhex a rdfs:Datatype . No trouble for me, as xhex is the set of ordered pairs from string to value, ie: xhex refers to { <"1" 1> <"2" 2> <"3" 3> ... <"1234" 4660> ....} and presumably an rdfs:Datatype is just a set of such ordered pairs. ie rdfs:Datatype refers to { ... { <"0" 0> <"1" 1> <"10" 2> <"11" 3> ... } { <"0" 0> <"1" 1> <"2" 2> <"3" 3> ... <"1234" 4660> .... }... ... } and indeed the set referred to by xhex is an element of the rdfs:Datatype set. > as a thing, so we can say that "it" is a datatype for example. ok, so you mean when using like this x :dollarValue "1234"^^:xhex . we are saying x dollarValue 4660 . I have no problem with that, because as you pointed out above, we can think of ^^ as just a shorthand for x :dollarValue 4660 . "1234" :xhex 4660 . And indeed the second sentence is true since the pair <"1234", 4660> is an element of the xhex set. And the first sentence is also true, because the dollarValue relates x to a number, and the value of x (let's assume) is indeed 4660 dollars . So we have not had to do any magic yet: xhex still points to our relationship. > Used as a class name, its the class of all the values. that's odd! When do we need this? Oh yes, because we want to say that the domain of something xhex a owl:DatatypeProperty; rdfs:domain xsd:string ; rdfs:range xhex . But for the above to make sense either: [A] xsd:string would have to refer to { "a string", "123", "another string", ... } and xhex would have to refer to { .... 0 1 2 3 4 5 6 7 8 .... } but just earlier we had xhex refer to a set of pairs, and xsd:string too... [B] the rdfs:range relation be a relation from sets-of-ordered-pairs (properties) to sets: - - where usually the range of the rdfs:range relation is a superset of the unions of all the elements in second position in the set of ordered pairs - but IF the range is literal, then the range of domain can be the exact same set as the domain xhex rdfs:range xhex . is true because xhex being a set of pairs, and rdfs:range just have been defined in this odd way, it's true. But why make something simple complicated just because we want to say that? In order to save just one new URL? Much easier to say :String is the set of all strings, and :Integer is the set of all integers, like this xsd:integer rdfs:domain :String; rdfs:range :Integer . Then it's much easier to understand what we are speaking about. > Used as a property, it is the string-to-value mapping. as I pointed out above, a property is a set of pairs, so there is no problem here. So it looks like we can be much clearer just by defining classes for literals instead of using xsd:integer and cert:easyHex both as a mapping and as a set of instances. [ but I imagine there is something I have missed here] This is then how one could define cert:easyHex: @prefix <http://www.w3.org/ns/auth/cert#> cert:easyHex rdf:type rdfs:Datatype; owl:inverseOf cert:hex; rdfs:range :Integer; rdfs:domain :String; rdfs:comment """ An encoding of a positive integer (from 0 to infinity) as a hexadecimal string that makes it easy to read and/or fun to present on the web. The purpose of this way of representing hexadecimals is to enable users to copy and paste hexadecimal notations as shown by most browsers, keychains or tools such as opensso, into their rdf representation of choice. There are a wide variety of ways in which such strings can be presented. One finds the following e1 dc d5 e1 00 8f 21 5e d5 cc 7c 7e c4 9c ad 86 64 aa dc 29 f2 8d d9 56 7f 31 b6 bd 1b fd b8 ee 51 0d 3c 84 59 a2 45 d2 13 59 2a 14 82 1a 0f 6e d3 d1 4a 2d a9 4c 7e db 90 07 fc f1 8d a3 8e 38 25 21 0a 32 c1 95 31 3c ba 56 cc 17 45 87 e1 eb fd 9f 0f 82 16 67 9f 67 fa 91 e4 0d 55 4e 52 c0 66 64 2f fe 98 8f ae f8 96 21 5e ea 38 9e 5c 4f 27 e2 48 ca ca f2 90 23 ad 99 4b cc 38 32 6d bf Or the same as the above, with ':' instead of spaces. We can't guarantee that these are the only ways such tools will present hexadecimals, so we are very lax. The letters can be uppercase or lowercase, or mixed. Some strings may start with initial 00's which would be very important if the number were in complement of 2 notation, where in some cases this could be the difference between a positive and a negative number, in particular if the number starts with one of [8-f]. But as we interpret this string as a hexadecimal number leading 00s are not important (Complement of 2 notation and hexadecimal overlap for positive numbers) In order to make this fun, we allow any unicode characters in the string. A parser should 1. remove all non hexadecimal characters 2. treat the resulting as a hexadecimal representation of a number This will allow people to make an ascii - better yet a UTF-8 - picture of their public key when publishing it on the web. """@en . > Pat Hayes > >> >> Henry >> >> >> [1] http://www.w3.org/TR/rdf-mt/#dtype_interp >> >> Social Web Architect >> http://bblfish.net/
Received on Monday, 22 February 2010 09:47:57 UTC