This is an extract from a dialog between Sean B. Palmer and myself:
> Overall, the article was very good indeed - you must have done an
> awful lot of background research! The one main (i.e. only) bit that I
> didn't get was:-
>
> > N3, RDF, or any other serialization has to be able
> > to identify by *every* application that consumes
> > triples. The only way to accomplish this is to include
> > a triple-syntax-identifier before the triples.
First, it contains a typo and then it is bit incomplete, should be: "One problem with this is: how do we identify a triple serialization format? N3, RDF, or any other (future) serialization has to be identifiable by *every* application that wants to consumes triples in a serialization-syntax independent way." But this does not change the fact that it might be a bad idea (below).
> The problem with this is that the triple-syntax-identifier is going to
> *have* to be in the same format as the triples themselves, for
> backwards compatability.
Hmm ... this was somewhere in the back of my head while writing ... but never surfaced. Perhaps certain Web Services (i.e. RPC with XML and HTTP POST -- SOAP) could be another solution. If some applications stumble across a resource with some odd triple serialization format, the application could send the URL to the resource as a parameter to a Web Service, and, if things work out, receive a set of triples in the basic standard triple format (perhaps a(o,v)). This means that an application needs to handle the basic serialization syntax and to be able to locate and invoke an appropriate Web Service in order to be syntax independent. This is just a way of making it easier to build the application, and this makes the application immune (different syntaxes should be transparent to the application) against future serialization formats.
I am currently writing a short paper (in a software architecture course) on the topic of Web Services and what effect it will have on the architecture of Web applications. I think that the concept of Web Services is a great, and that the SW will benefit form them being developed, and the Web Services community need some help from the SW community especially concerning Web Service metadata. (e.g. use RDF instead of WSDL to describe the service (as mentioned by Uche Ogbuji in [1])).
> Anyway, I think that the
> whole notion of "format conversion" is indeed an important thing, but
> one that will evolve very randomly, rather than as one cohesive effort
> on the behalf of all the SW developers. Note that at this state there
> aren't really all that many RDF formats around... in fact there are
> three languages, and two syntaxes that I know of; languages: XML RDF,
> Notation3, and semEnglish; syntaxes: s p o (tab-delimited format) and
> p(s,o).
Web Services would only help, and not constrain people and does not demand "one cohesive effort". I will rewrite the article and focus on the help that Web Services can provide in this matter. All this got me into the roles of Web Services and the SW, so I will shortly present an article on that too.
> BTW, RDF and XML Schemas do overlap slightly, but not in the way that
> you have represented it: their actual syntaxes don't really overlap,
> but some of the datatypes can. For example, see the latest DAML
> release [3] which contains some terms from the XSD namespace (well,
> the actual namespace is incorrect, but that's a bug).
I will update the article and use the more general terms "schema A" and "schema B". I know that there isn't much of a semantic overlap between XML Schemas and RDF(S) so it's a bad way of using them in my article.
[1] Superscaling WSDL with RDF -- Managing structured Web service
metadata
http://www-4.ibm.com/software/developer/library/ws-rdf/index.html