Re: on independence of elements, relating versions [XMLVersioning-41]

Joshua Allen wrote:

>>misunderstanding your answer).  Let's assume we indeed had 
>>whatever was the "ideal" XML serialization of RDF, the one 
>>    
>>
>...
>  
>
>>Question:  to what extent would XML -based tools then be a 
>>first class  means of doing RDF queries?   I still have an 
>>    
>>
>
>  
>
Hmm, I have my doubts about the "first class" part there. That queries 
can be done this way isn't in doubt - XSLT is Turing complete and has 
been applied to RDF/XML (albeit slowly). I haven't spent time with TriX 
yet, but I believe a certain set of queries should be pretty immediately 
available using XPath. But I'm not sure how generally applicable this 
can be -  XML tools generally  take advantage of the XML tree, RDF is a 
graph, we're back to the fundamental mismatch.

>This is a very insightful question.  In fact, I believe that the example of RSS 1.0 (the version of RSS that is based on RDF) proves your concerns to be valid.  Many news aggregator applications have "support" for RSS 1.0, using naïve XML parsers.  However, if the RDF of the feed is serialized using a triple-oriented format analagous to TriX, most news aggregators would break.  The whole ecosystem works, for now, because producers of the RSS 1.0 feeds are careful to emit files that conform to the XML format that the aggregators expect.  In other words, RSS 1.0 claims to be an RDF vocabulary, but in practice it ends up being an XML schema.
>  
>
I'd take a slightly different view - it isn't RDF or XML, but both. RSS 
1.0 does more than claim to be RDF - any standard RDF tool can consume 
RSS 1.0. I think it's worth noting that many RSS tools only actually 
support XML in a limited fashion - the proliferation of ill-formed docs 
has meant regexps make a good parser. I would be surprised if many 
aggregators supported namespaces correctly.

>Introducing bnodes, as any triple-oriented format must do, is almost guaranteed to break the people who "support" RDF with naïve XML parsers.  
>  
>
I don't believe that bnodes are necessarily the problem - RSS 1.0 
includes one (the items Seq).

>Now, I personally feel that a triple-oriented syntax is warranted, and should be used in favor of the current XML/RDF syntax.  The fact that some users can muddle along with the current syntax is an unreliable and brittle bug, IMO.  It's sheer luck that it ever works for these news aggregators in the first place, and only the aggregators who use actual RDF parsers (there are some) should expect it to work.
>  
>
My opinion is that there is space for a syntax like TriX, but that this 
doesn't mean RDF/XML isn't useful, or shouldn't remain the interchange 
format. However I'm not convinced that the restricted-RDF/XML approach 
as used in RSS 1.0 syntax is helpful, because although it brings in the 
use of XML tools it effectively excludes most RDF interop.

I'm not sure, but I think there may be a way forward close to the GRDDL 
approach. Take for example Atom. This will have a single 
tightly-specified XML serialisation. But there is demand for this data 
to be used in RDF systems. Ok, so let's have a normative RDF mapping 
(this has been kind-of agreed). An easy way of specifying that mapping 
is through an XSLT stylesheet from Atom to RDF/XML (with an associated 
RDFS/OWL ontology). Whether or not the consumer systems use the 
stylesheet or a custom parser doesn't matter, the XSLT provides the map.

What's lacking is the conversion from arbitrary RDF/XML and into Atom. 
But I think a general solution to this might best move the conversion 
inside theRDF/XML producer, where it would appear as an XML writer 
system. I believe most RDF APIs would support the kind of filtering need 
to extract the pertinent triples. The extra needed is a binding declared 
between particular typed nodes and elements (/attributes) in the desired 
serialization, to 'channel' the data into the right places. This 
subsystem could operate much like XSLT's recursion, except acting on the 
graph rather than a tree. I've a feeling that if such a system were 
worked out for one language/API, it would be relatively straightforward 
to use it in others.

With RSS, there is the 'local' data model of the syndication domain, the 
RDF expression of that, and the XML serialization which happens to be a 
sublanguage of RDF/XML. If we rearrange the picture a little for Atom, 
again we have the 'local' data model and it's RDF expression, but the 
primary serialization would be Atom/XML.

Cheers,
Danny.

>
>  
>