W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > November 2001

RE: DATATYPES: mental dump.

From: <Patrick.Stickler@nokia.com>
Date: Wed, 14 Nov 2001 22:22:57 +0200
Message-ID: <2BF0AD29BC31FE46B78877321144043114C09C@trebe003.NOE.Nokia.com>
To: phayes@ai.uwf.edu, w3c-rdfcore-wg@w3.org
Cc: pfps@research.bell-labs.com

> S. (Sergey)
> 
> 
> Quite local, in that literals are ...  Example:
> 
> 
> aaa eg:prop _:x .
> _:x xsd:integer "10" .
> 


Sorry if I missed an example of this, but how would the above be
represented in RDF/XML?

Like this?

<rdf:Description rdf:ID="aaa">
   <eg:prop>
      <rdf:Description>
         <xsd:integer>10</xsd:integer>
     </rdf:Description>
   </eg:prop>
</rdf:Description>

???

I.e. what are the implications of having to have a bNode
between every property and its literal value?

How about the RDF/XML representations for the other
proposals?

Just because a proposal is "compatible with" the present
RDF/XML serialization doesn't mean that its representatation
is palatable.

Here's a stab at the examples provided in Pat's mental dump
re-expressed in RDF/XML as best as I can figure. If anyone
thinks there's a better way for a given case, please suggest it.

--- 

U. (Patrick)  (formerly X, the URV proposal)

aaa eg:prop <xsd:integer:10> . 

<rdf:Description rdf:ID="aaa">
   <eg:prop rdf:resource="xsd:integer:10"/>
</rdf:Description>



S. (Sergey)

aaa eg:prop _:x .
_:x xsd:integer "10" . 
 
<rdf:Description rdf:ID="aaa">
   <eg:prop>
      <rdf:Description>
         <xsd:integer>10</xsd:integer>
     </rdf:Description>
   </eg:prop>
</rdf:Description>



DC. (Dan)

aaa eg:prop _:x .
_:x rdf:label "10" .
_:x rdf:type xsd:integer .

<rdf:Description rdf:ID="aaa">
   <eg:prop>
      <rdf:Description>
         <rdf:label>10</rdf:label>
         <rdf:type rdf:resource="&xsd;integer/>
     </rdf:Description>
   </eg:prop>
</rdf:Description>


P. (Peter)


Not local at all, in that literals are assigned a datatype indirectly, by
declaring a datatype to be the range of the property used in the triple. The
range information might be anywhere in the graph, and need not be 'close' to
the triple including the literal. Example:


aaa eg:prop "10" .
eg:prop rdfs:range xsd:integer .

<rdf:Description rdf:ID="aaa">
   <eg:prop>10</eg:prop>
</rdf:Description>
<rdf:Description rdf:about="&eg;prop">
   <rdfs:range rdf:resource="&xsd;integer"/>
</rdf:Description>



P++. (Pat)

aaa eg:prop _:x:"10"  .
_:x rdf:type xsd:integer .


<rdf:Description rdf:ID="aaa">
   <eg:prop rdf:resource="#x"/>
</rdf:Description>
<rdf:Description rdf:ID="x">
   <rdf:label>10</rdf:label>
   <rdf:type rdf:resource="&xsd;integer"/>
</rdf:Description>

??? How does one define the literal node label in
RDF/XML serialization for the P++ proposal? 

If one has to use a property of the bNode, then
are the differences between P++ and DC all that
great? Or are they just notational variants?

E.g. is the representation of P++ also

<rdf:Description rdf:ID="aaa">
   <eg:prop>
      <rdf:Description>
         <rdf:label>10</rdf:label>
         <rdf:type rdf:resource="&xsd;integer"/>
      <rdf:Description>
   </eg:prop>
</rdf:Description>

I.e., identicial to DC... ???


X (Patrick)

<rdfg:SNode rdf:ID="N1">
   <rdfg:subject   rdf:resource="#N2"/>
   <rdfg:predicate rdf:resource="#N3"/>
   <rdfg:object    rdf:resource="#N4"/>
</rdfg:SNode>
<rdfg:UNode rdf:ID="N2"  rdfg:label="#aaa"/>
<rdfg:UNode rdf:ID="N3"  rdfg:label="&eg;prop"/>
<rdfg:LNode rdf:ID="N4"  rdfg:label="10"/>
<rdfg:SNode rdf:ID="N5">
   <rdfg:subject   rdf:resource="#N1"/>
   <rdfg:predicate rdf:resource="#N6"/>
   <rdfg:object    rdf:resource="#N7"/>
</rdfg:SNode>
<rdfg:UNode rdf:ID="N6"  rdfg:label="&rdf;type"/>
<rdfg:UNode rdf:ID="N7"  rdfg:label="&xsd;integer"/>

Note, however, that the X proposal suggests an underlying
model for interpretation and processing, not necessarily
for serialization and interchange, and certainly not for
humans ;-)

---


I think that expressability in RDF/XML should be taken into
account in considering the proposals.

Regards,

Patrick
Received on Wednesday, 14 November 2001 15:23:13 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:42:40 EDT