- From: Richard Light <richard@light.demon.co.uk>
- Date: Fri, 15 Jan 2010 12:10:45 +0000
- To: semantic-web@w3c.org
>2010/1/15 Jeremy Carroll <jeremy@topquadrant.com>: >> Steve Harris wrote: >>> >>>> * an RDF/XML profile (as above) designed for maximum compatibility >>>> with XPath/XSLT/XQuery >>> >>> That would be nice. I often thing that RDF/XML is not a terribly >good way >>> to encode RDF in XML. +1 I think there is the opportunity to go for an 80/20 update to RDF, analogous to the move from SGML to XML. I support the "simplification" approach (triples only; no more complex structures), while agreeing with the proviso that there must be some means of making a statement about a statement or set of statements (for authority/trust/metadata purposes). With such a simple approach, a new XML serialization of RDF can likewise be totally simple, and self-evident to human eyeballs. This will have two positive benefits: - it finesses the need to proliferate alternative serialization formats (e.g. Turtle), each of which requires the development of a totally separate toolchain before data expressed in it can be used; - it makes the serialized RDF directly machine-processible using standard XML-based mechanisms, as suggested above. For example, it would be easy using XSLT keys to grab all the statements with a certain URI as subject, and thereby represent one node in the RDF graph. If we can stay with XML as the default RDF serialization, we can go further. At present, Linked Data resources allow you to put queries, and get a bit of Linked Data back. In some cases, this query result will contain information that is directly useful in its own right, but frequently the enquirer will be after the URIs it contains. For example, I might put a museum-oriented query, to find long case clocks made in London in the 1820s, and now in U.K. museums. (I wish!) The result of this fictitious query will include the URIs of said clocks. I can stay in Linked Data mode, e.g. with a SPARQL Describe request, and grab all the RDF statements about my result set. The result would look like the output of most Linked Data browsers. However ... What if I could use those URIs to access a rich textual description of each clock, expressed in XML and using that thing called natural language, which is so much more meaningful to readers than RDF statements? This is to some extent possible now, with luck and a following wind, using the 303 strategy and suitable HTTP Accept headers. However, the 303 approach seems to want to equate "human-readable" with an HTML representation of the resource. I want the resource to be in XML, so that I can continue machine-processing it, e.g. selecting relevant parts of each clock's description. This direction of travel would be helped if RDF learned a lesson from Topic Maps, and made a proper distinction between subjects (=Topics) and resources (=Occurrences), e.g. by adding rdf:subject (which would have an IRI as value). Then we could make statements such as "the Subject XXX is defined by the resource YYY" and "the Subject XXX is defined, in French, by the resource ZZZ", where YYY and ZZZ are XML resources. This also gets us round the current irritating limitation of having to use a single string to define any concept. Developing this approach, it becomes possible to imagine publishing a subject as a self-contained chunk of XML containing both the RDF statements you currently get, but also one or more full-flavour XML resources defining that subject in machine-processible, human-readable form. This would be both easier to produce and manage, and easier and more useful to consume, than the current approach. >There was the clunky 1998/99ish RDF/XML stuff which had eyeballs from >xml-dev on it, but until relatively recently it seemed like the XML >world and the RDF world were completely different planets. Now with >the likes of Jeni & Bob DuCharme jumping on board the RDF raft it >seems there is real crossover. (Not to mention the OpenLink one store, >many views approach). Kudos to the Linked Data initiative for that ... Richard (another one from XML-land) -- Richard Light
Received on Friday, 15 January 2010 12:11:21 UTC