Re: hiding RDF

On Feb 12, 2004, at 3:24 AM, Andrew Newman wrote:

>> intriguing approach your :) I found especially tasty the solution you 
>> give how to add provenance/context information to RDF graphs - is 
>> there any parser or software supporting your new syntax or XSLTs to 
>> convert TriX syntax to full-blown RDF/XML?
>
> I was hoping for an improvement to the original RDF/XML syntax and 
> basically got N3 meets XML.  Not a bad thing mind you, for machine to 
> machine transmission and integration into existing XML tools which I 
> think was the point.  But I think that later maybe fairly limited it 
> doesn't seem to solve enough problems.
>
> I know when I'm using N3 and I suspect with TriX putting the 
> statements back together again (frames(?), properties hanging off the 
> resources) is what I'll end up doing.

I think the current RDF/XML is doing a fine job for Web graphs - as 
well as TriX (or any other N3, N-triples or whatever) will do - but we 
also need to define some profiles for RDF to easier the job of 
embedding (or hide) statements into XML - the latest changes to the 
RDF/XML syntax has been giving some hope by making rdf:RDF element 
optional, then allowing to parse almost any well-formed XML as RDF 
(which might require to use rdf:parseType="Resource" all over the 
places and avoid property elements to have multiple object node 
elements). XSLT can do the job for me but then we need those profiles 
defined there then - which then would help the user to make its XML RDF 
friendly and vice-versa. Great!

>
> I have a hard time imagining that it will make it possible to use XSLT 
> and take a RSS 1.0 feed and transform it into an RSS 2.0 feed. 
> Although, anything is possible with XSLT but we have to make sure it's 
> the best choice.  I'd like an example showing that this is the best 
> approach.  Other approaches, like mapping known RDF data to an XML 
> vocabulary seems easier to me.
>
> The addition of naming graphs is definitely a good thing.

even though I am wondering how those TriX IDs for naming graphs map 
back into the original RDF/XML syntax - I guess some reification is 
needed in there :) right?

>
>> anyhow - while playing here with some pilot projects and trying to 
>> sell RDF based solutions to real customers we found very hard selling 
>> the XML "bits" of RDF, unless we have a good/smart/clever way to 
>> "hide it" behind some more familiar XML shell. Your paper (and 
>> others) seems touching this issue at different levels - but we have 
>> to admit that we still have problems  convincing customers to buy RDF 
>> "specific" syntaxes like your TriX - while using them, users are 
>> generally scared away - unless it resembles something more familiar 
>> to simple "what-you-see-is-what-you-mean" well-formed XML.
>
> RDF/XML is actually an improvement over many home grown XML 
> serializations that I've come across that I trying to do the same 
> thing i.e. describe a graph based system.

then RDF/XML, TriX or any other dialect of RDF is the way to go - and 
by using TriX you would get the additional provenance info for free - 
plus the XSLT bits...

> If you have to provide a user with an XML format get them to define it 
> and create it directly out of your triple store.  There really doesn't 
> seem to be a requirement there for an XML format of triples, in that 
> respect.

right - and 90% of the time that XML is far from being RDF parseable or 
that can be transformed easily to RDF - unless we explain them how to 
do it :-)

>
> I'm not sure how TriX is solving the human readability problem, if 
> anything the paper seems to suggest that RDF/XML is more readable than 
> simple triple based formats and it is still machine readable.  I find 
> it cumbersome to think in triples and I would imagine most developers 
> would as well.

yes me too - but I do not have other choices today if I want to use RDF 
;)

cheers

Alberto

>
>> a part RPV - have you (or other people on this list) ever gave a 
>> closer look to more XML "friendly" (or lightweight) approaches to RDF 
>> like the xemantics TAP approach?
>> http://tap.stanford.edu/xemantics.html
>> at first sight it looks quite what an XML user would love to see or 
>> use :)

Received on Friday, 13 February 2004 05:26:31 UTC