Boris,<br><br>I will try to test XSD with the RSS 2.0 schema you point out. Glancing at the schema, do you see<br>anything that might cause XSD to malfunction ?<br><br>I am trying to familiarize with XSD before thinking of using it with RDF schemas.
<br><br>Thanks and regards,<br>Jose<br><br><br><br><div><span class="gmail_quote">On 1/31/06, <b class="gmail_sendername">Boris Kolpackov</b> <<a href="mailto:boris@codesynthesis.com">boris@codesynthesis.com</a>> wrote:
</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Jose,<br><br>Jose <<a href="mailto:jmalv04@gmail.com">jmalv04@gmail.com</a>> writes:
<br><br>> Before considering the RDF schema I would like to know whether XSD can<br>> tackle parsing the RDF file as XML.<br><br>You probably mean if XSD (the tool) can generate the code to parse<br>RDF as an XML.<br>
<br>> That by itself would make XSD very useful to me. I imagine it's<br>> possible but I am not sure<br>><br>> Here is a sample for RSS RDF<br><br>It is definitely possible if you can come up with an XML Schema
<br>definition for your RSS RDF. Looking at the instance below it looks<br>very similar to an RSS instance with RDF extensions. There is an<br>XML Schema for RSS 2.0 available:<br><br><a href="http://www.thearchitect.co.uk/schemas/">
http://www.thearchitect.co.uk/schemas/</a><br><br>hth,<br>-boris<br><br>> <?xml version="1.0" encoding="utf-8"?><br>> <rdf:RDF xmlns:rdf="<a href="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
http://www.w3.org/1999/02/22-rdf-syntax-ns#</a>"<br>> xmlns:dc="<a href="http://purl.org/dc/elements/1.1/">http://purl.org/dc/elements/1.1/</a>"<br>> xmlns:rss="<a href="http://purl.org/rss/1.0/">
http://purl.org/rss/1.0/</a>"<br>> xmlns="<a href="http://purl.org/rss/1.0/">http://purl.org/rss/1.0/</a>"><br>> <channel rdf:about="<a href="http://dig.csail.mit.edu/breadcrumbs/blog/4">http://dig.csail.mit.edu/breadcrumbs/blog/4
</a>"><br>> <title>timbl's blog</title><br>> <link><a href="http://dig.csail.mit.edu/breadcrumbs/blog/4">http://dig.csail.mit.edu/breadcrumbs/blog/4</a></link><br>> <description></description>
<br>> <items><br>> <rdf:Seq><br>> <rdf:li rdf:resource="<a href="http://dig.csail.mit.edu/breadcrumbs/node/72">http://dig.csail.mit.edu/breadcrumbs/node/72</a>"/><br>><br>> <rdf:li rdf:resource="
<a href="http://dig.csail.mit.edu/breadcrumbs/node/71">http://dig.csail.mit.edu/breadcrumbs/node/71</a>"/><br>> <rdf:li rdf:resource="<a href="http://dig.csail.mit.edu/breadcrumbs/node/62">http://dig.csail.mit.edu/breadcrumbs/node/62
</a>"/><br>> <rdf:li rdf:resource="<a href="http://dig.csail.mit.edu/breadcrumbs/node/54">http://dig.csail.mit.edu/breadcrumbs/node/54</a>"/><br>> <rdf:li rdf:resource="<a href="http://dig.csail.mit.edu/breadcrumbs/node/38">
http://dig.csail.mit.edu/breadcrumbs/node/38</a>"/><br>> </rdf:Seq><br>> </items><br>> </channel><br>> <item rdf:about="<a href="http://dig.csail.mit.edu/breadcrumbs/node/72">
http://dig.csail.mit.edu/breadcrumbs/node/72</a>"><br>> <title>Backward and Forward links in RDF just as important</title><br>><br>> <link><a href="http://dig.csail.mit.edu/breadcrumbs/node/72">
http://dig.csail.mit.edu/breadcrumbs/node/72</a></link><br>> <description>&lt;p&gt;&lt;em&gt;&lt;a<br>> href="<a href="http://www.ctaz.com/~dmn1/hein.htm">http://www.ctaz.com/~dmn1/hein.htm
</a>"&gt;Piet Hein&lt;/a&gt;, I<br>> think, &lt;a href="<a href="http://chat.carleton.ca/~tcstewar/grooks/grooks.html">http://chat.carleton.ca/~tcstewar/grooks/grooks.html</a>"&gt;Grooked&lt;/a&gt;
<br>> that,&lt;/p&gt;<br>><br>> &lt;p&gt;"Two types that had far better leave to their betters&lt;br /&gt;<br>> the civilized art of exchanging letters&lt;br /&gt;<br>> are those who disdain to make any response,&lt;br /&gt;
<br>> and those who infallibly answer at once!"&lt;/p&gt;<br>> &lt;p&gt;The regularity of this blog fails on both counts.&lt;/em&gt;&lt;/p&gt;<br>><br>> &lt;p&gt;One meme of RDF ethos is that the direction one choses for a
<br>> given property is arbitrary: it doesn't matter whether one defines<br>> "parent" or "child"; "employee" or "employer". This philosophy (from<br>> the Enquire design of 1980) is that one should not favor one way over
<br>> another. One day, you may be interested in following the link one<br>> way, another day, or somene else, the other way. &lt;/p&gt;<br>> &lt;p&gt;On the other hand, also one should not encourage people
<br>> having to declare both a property and its inverse, which would simply<br>> double the number of definitions out there, and give one more axis of<br>> arbitrary variation in the way information is expressed. Therefore,
<br>> the design of the tabulator was is to make the system treat forward<br>> and backward links equivalently.&lt;/p&gt;<br>> &lt;p&gt;The design of &lt;a<br>> href="<a href="http://www.w3.org/DesignIssues/Notation3">
http://www.w3.org/DesignIssues/Notation3</a>"&gt;N3&lt;/a&gt; also<br>> was influenced by this. The ability to write&lt;/p&gt;<br>><br>> &lt;p&gt;:Joe is f:parent of :Fred.&lt;/p&gt;
<br>> &lt;p&gt;makes it easier to write (or generate) N3 without having to<br>> use f:child. This in turn reduces the pressure to define<br>> both.&lt;/p&gt;<br>> &lt;p&gt;The only loss in not having both is that there is no label
<br>> for the reverse link. (In same cases I have defined an unnamed<br>> predicate which is delcared as the inverse and has a label.)&lt;/p&gt;<br>> </description><br>> <dc:date>2006-01-25T16:21:17Z</dc:date>
<br>> </item><br><br><br>-----BEGIN PGP SIGNATURE-----<br>Version: GnuPG v1.2.5 (GNU/Linux)<br><br>iQGVAwUBQ9+HOciAKQuuCE8dAQINRQv9FB1w793s6Vey9aV1EOjJI3+8Q8jh/+NS<br>VhyIqs7StAYN0GZIIuuaMhvsezVMnwfwipLmYoSg6ao8C2bAAuQrbSBaI10lOyJ0
<br>RgdOqw2ibPp3zhw5CJx2Y4V/rlD5jd6BuzB0v5U41kACrQm/8LnksPs0LWzx8y7C<br>wHqJ7GQEX2gx2G8S6SNnbaMSjUxttJaq0t3i8yyKqxR4DRk6k09Dk6kYhM2zHCQE<br>afsredi8RPkaBUyJDSODVqpEex8uXKJ/UxvLFTavt2PttTahu63C5BVHO4VexvRS<br>mF8yMs7b4PRtG//turKxHnHy8MkDY1LujBhr6LQleYQDBu5JfKLsIjF5SSwXj0BJ
<br>QrQBv+Vpi1C5KtYi1XE9kgeTjG3knRxxD0VR3AhTPUol8aQgebNubbVTM8nnhLU6<br>CrRLh7fNc/1Rk00FKYRgc0eGPkGyE/4yjAgaoIlpVlzkQMGyAuxXfFvKmq2Sf+IE<br>T/n0QQSpSwpxXjktv0TJmd2h5K6LF0+j<br>=z/Wz<br>-----END PGP SIGNATURE-----<br><br><br>
</blockquote></div><br>