Re: LC: Opposing OWL/XML format

On 27 Jan 2009, at 15:50, Jonathan Rees wrote:

> On Jan 27, 2009, at 4:55 AM, Bijan Parsia wrote:
>
>>> GRDDL... well, if we had a 'standard' mapping from OWL/XML to RDF/ 
>>> XML
>>> via a GRDDL transformation then this could be a very good  
>>> argument here
>>> in favour of OWL/XML. And we may have that, right?:-)
>>
>> Well, I think we do already :) But if you mean an XSLT, then we  
>> can do the wrapper thing quickly. Rees indicated that that wasn't  
>> acceptable!
>>
>> Verra strange.
>
> Sorry to pop back into the WG after paying it no attention for  
> months. (I really wish I had a lot more time to put into OWL.) I  
> hope it's OK for me to hop the wall from the comments list to this  
> one.

Sure.

> Maybe you missed where I said my reason to dislike the web service  
> (XSLT+CGI) was that it was complicated and fragile.

I don't think it is. Certainly not *more* complicated and fragile.

> I think you should investigate using a real XSLT that is more  
> easily invoked locally,

Locality doesn't make it less complicated and fragile. I see no  
connection between them.

If by fragile you mean "more sensitive to being connected to a  
network and network conditions", then yes. But that's hardly the only  
consideration. Indeed, if you have a GRDDL agent which has not  
encountered OWL/XML before, it'll have to hit the network anyway (on  
the popular reading).

> as I assume you had intended  to do before Alan sidetracked you  
> with the CGI hack.

Not at all. First, I oppose having a downloadable XSLT for GRDDL at  
the namespace URI on a variety of principles. We had HUGE discussions  
about this both here and with the GRDDL WG.

Second, I proposed the "CGI hack" as a sorta reductio ad absurdum. To  
my surprise, people liked it and oh well.

> That ought to be straightforward (although I don't know, since I  
> haven't tried it) and would remove this objection. Put the XSLT  
> informatively in your document and you're done.

The problem is that people don't want it informatively. I don't know  
the point of having an informative implementation in a specific  
format. Why not just let implementers implement? If there is demand  
for this, it will emerge.

> One reason - maybe the only reason - to standardize a notation is  
> to reduce the number of ways to things are written.

That may be a prima facie reason, but that cat is waaaaay out of the  
bag, esp. with regard to OWL.

> I think this is an a priori reason to oppose additional syntaxes,  
> and it puts Frank van Harmelen on the high ground.

I don't think so. There are ample reasons to have an XML friendly  
syntax and no substantive reasons I can see to oppose it. Having the  
prima facie ground is *not* the same as having the high ground.

*All other things being equal*, Frank has a point. And if there were  
*no* considerations against him, he'd win. But I don't think we have  
to accord extra special strong weight to a prima facie point. I think  
making OWL open to the legions of XML developers is a big win. We  
really can't get that with RDF/XML.

> You standardize in order to limit options, including superior ones,  
> making a choice to sacrifice flexibility and utility for stability  
> and uniformity.

Yes, I want only one XML friendly OWL syntax. Hence my  
standardization. It doesn't really compete with RDF/XML.

> I see your point about XML toolchains.

Thanks.

> The question is a judgment call on the acceptable burden on those  
> creating OWL processors.

Why wouldn't it be?

> Each straw you add - each new syntax or feature - could break some  
> camel's back.

So, making every XML editor handle OWL well with no work on those  
developers, allowing people to write tools in XSLT, XQuery, etc.,  
breaking the perception that the semantic web is hostile to XML,  
allowing people to use owl in web services is negligible, but someone  
might not implement their own native parser *AND* refuses to use an  
existing one *AND* refuses to let people translate on their own?

It's a judgement call, but not a hard one I think. Everything in OWL  
has this judgement call, including the choice to evolve it at all.

> Maybe that would be a camel you don't care about.

I don't see that the camel exists. I especially don't see that the WG  
has to standardize or provide a specific implementation. I was  
working on the XSLT transform but I *stopped* because I don't want it  
distributed by the W3C. If an XSLT is sufficient, then it will  
happen. It doesn't  have to happen via GRDDL.

I've never seen ANY of the people complaining about OWL/XML complain  
similarly about Turtle (*I've* complained about it  :) though I was  
involved in its making!). Turtle has independent justification for  
its existence. OWL/XML does too. Think of it as the "Turtle for XML  
people" :)

> I'm making the judgment call that local XSLT is OK (because XSLT is  
> pervasive),

XSLT is much less used than Java. By orders of magnitude.

> web service is not (fragile), open source Java application is not  
> (complex and fragile).

Compared to XSLT? That's not my experience. One of my qualms is the  
lack of robustness, error handling, scalability of such an XSLT which  
would be essentially frozen.

Plus, I don't see why this isn't solved by the emergence of an XSLT,  
rather than the group producing one. If you like XSLT, encourage  
people to built one. Mine would be nearly finished if not for people  
wanting something like that as a product of the group.

> You might ask Frank's group whether they would agree with me, or if  
> even given published XSLT they would feel the burden is too high.
>
> I'm a bit skeptical about Ivan's claim that RDF/XML is the only  
> required exchange format.
> Even if this is made clear (sorry, I haven't encountered this  
> statement yet, can you tell me where it is?)

http://www.w3.org/2007/OWL/wiki/ 
Conformance_and_Test_Cases#Conformance_.28Normative.29

> there is a chance that a recommendations to use all formats will  
> lead to irresistible pressure to accept all formats.

Uhm...if there is irresistible pressure, presumably it will be  
because enough people are using it to make it worth people's while.  
If so, what's the problem? If there isn't key or enough people using  
it, where's the irresistibility?

> If you're saying OWL/XML is going to exist no matter what, and  
> should therefore be standardized, that's a bit different from the  
> way it looks now - which is like a buffet where a picky eater can  
> choose whichever dish they like best.

? I don't know where I said this. Unfortunately, while being a  
recommendation does not ensure success, lack of being a  
recommendation can ensure failure. Many organizations can't or won't  
touch non-rec stuff (or the barrier becomes artificially high and not  
technical). (Often in government cases.)

I'd *much* rather wean XML bigots on the OWL/XML and *then* to RDF.

> The story has to be instead that you have multiple screw sizes  
> because of different application requirements (toolchain, installed  
> base, etc.).

This is my story.

> Any time you can recommend that certain forms *not* be used for  
> certain applications (e.g. OWL/XML should not be used for exchange)  
> that will make life easier for developers.

Well, not for OWL/XML centric people. Right now, I write programs to  
generate OWL/XML because I use XML tools and it's much easier to  
validate, generate, etc. if I do that. To exchange in a usefully  
broad way, I have to generate RDF/XML as well. And I do (see the  
manchester owl repository). That's a burden in some sense, but hardly  
a huge one, esp. in proportion to the greater interoperability.  
So...er...what's the problem?

> (Creating a media type for OWL/XML looks to me like an endorsement  
> of its use for exchange, but probably I read too much into  
> "Intended usage - COMMON, Restrictions on usage - None" in section 4.)

I don't think it's unreasonable to publish OWL/XML on the web. The  
point is to also publish RDF/XML. Having a MIME type allows for  
content negotiation so that *if* you support or prefer OWL/XML, you  
can get that instead. I would be *non conforming* if I pubished a  
site that returned *only* OWL/XML. But that I *do* return OWL/XML *as  
well* is also conforming. Heck, I can return Turtle if you like (and  
many people do). That doesn't make Turtle the normative exchange  
syntax. Nor NTriples, for that matter.

(MIME type also helps with embedding in other formats, typing, etc.  
E.g., MIME type can be used in WDSL.)

We can't eliminate the risk that OWL/XML will become so wildly  
popular that existing editors will be driven out by XMLSpy, oXygen,  
etc. I don't see it likely, but there is that risk! :) But, y'know,  
Oracle producing an OWL product could kill RDF Gateway or, for that  
matter, Pellet. I don't think these are likely (i.e., I think  
Oracle's presence will grow the market) but there is that risk.

We have to judge how  likely the risk is.

> In any case, if OWL/XML stays,

Manchester would formally object if it went or became informative. I  
think the technical arguments are overwhelmingly in its favor, so I  
would expect that the director would support the objection. I think  
it's hard to argue against adding a serialization that allows for so  
many W3C core technologies to work with OWL isn't worth the candle,  
esp. given that you are not remotely eliminating support for interop  
with RDF.

> I hope that later drafts of the new features document capture much  
> of what you have just provided as a rationale. I found it informative.

I'm glad. I think it will.

Cheers,
Bijan.

Received on Tuesday, 27 January 2009 16:25:51 UTC