Re: how to define that a relation is a dataype?

On Feb 22, 2010, at 12:50 PM, Story Henry wrote:

> On 22 Feb 2010, at 19:28, Dan Connolly wrote:
>> On Mon, 2010-02-22 at 10:19 -0800, Jeremy Carroll wrote:
>>> [...] Real people don't type triples ... so there is going to be  
>>> some
>>> transform somewhere, and transforming to the second batch is no  
>>> harder than the first.
>>
>> Fair enough... though... Henry does seem to be concerned with how
>> it looks a s RDFa markup. I haven't thought thru what the 2nd
>> batch looks like if you go back to RDFa.
>
> Yes, I was quite happy to use a cert:hex as a relation with a  
> similar role to a datatype, because its easy to understand. So this  
> is how we defined cert:hex
>
> :hex a owl:DatatypeProperty,
>     owl:InverseFunctionalProperty;
>   rdfs:label "hexadecimal"@en .
>
> It's easy to understand, and easy to explain. We have an inverse  
> functional relation and I know how those work.
>
> In n3 we even get it to look nice with
>
> x euros "AA"^cert:hex .
>
> But it stops us using some nice features in rdfa. So things are a  
> bit more complicated for people to write out, as can be seen here:
>
>  http://lists.foaf-project.org/pipermail/foaf-protocols/2010-February/001692.html
>
> This is not a good thing, so if we can avoid it, I'd be happy.
>
> And I have no trouble creating an inverse of cert:hex to be the  
> literal. If that is the right thing to do, then that's great. We  
> could define:
>
> :hexType a rdfs:Datatype ;
>   owl:inverseOf cert:hex ;
>   rdfs:label "hexadecimal"@en .
>
> and have
>
> x euros "AA"^^cert:hexType .
>
> But I want to do things right, and for that I have to understand  
> literals, which somehow is just not that easy.

Is it really all that complicated? Here is a summary of typed  
literals. A datatype URI identifies a mapping from strings to values.  
The value of the typed literal  "string"^^dtype is the value of the  
mapping applied to the string: in normal mathematical notation, it is  
just  dtype(string).

> So now I am reading through the rdf-semantics specification. Its  
> interesting, but it does seem somehow overly complicated.

Its complicated largely because it has to work for *any* datatype or  
set of datatypes. But the heart of it is what I said just above.

> (Still need to come to a conclusion)
>
> Now literals as relations make a lot of sense. That is why I'd like  
> to understand the relation between literal types and relations. It  
> seems that the following is true
>
> { bgt euro "1.2"^^xsd:float } => { bgt euro "1.2"^[ is xsd:float of] }
>
> It would be really great if one could come to some generalised  
> conclusion on this.

I don't understand your notation here. I guess [is FOO of] means the  
property of a value which gives the string representation of that  
value under the FOO convention, so that "1A" is hex of 26 . (??)  If  
that is right, then your suggested entailment seems wrong, above. But  
this would be OK:

bgt euro "1.2"^^xsd:float .

=>

bgt euro _:x .
"1.2" is xsd:float of _:x .

and this pattern generalizes, of course. However, this has a literal  
subject, so its not legal RDF. Whereas this

bgt euro _:x .
_:x  xsd:float "1.2" .

is legal RDF :-)

Hope this helps.

Pat


> Because that would just make literals very easy to understand. It  
> could also help reason about them.
>
> Henry
>
>>
>>
>>> then
>>>
>>> all the following is true as well:
>>>
>>>
>>>
>>> _:b1234 owl:sameAs "1234"^^xsd:int .
>>>
>>> _:b1234 owl:sameAs "TU"^^:base64;
>>>    owl:sameAs "4D2"^^:hex ;
>>>    owl:sameAs "1234"^^:dec ;
>>>    owl:sameAs "2322"^^:oct ;
>>>    owl:sameAs "11010010"^^:bin .
>>
>>
>> -- 
>> Dan Connolly, W3C http://www.w3.org/People/Connolly/
>> gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E
>>
>
>

------------------------------------------------------------
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 20:56:50 UTC