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