W3C home > Mailing lists > Public > public-owl-wg@w3.org > January 2009

Re: LC: Opposing OWL/XML format

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Wed, 28 Jan 2009 15:04:44 +0000
Message-Id: <9401F7A2-6143-4AB1-96B6-48D9BAA5C400@cs.man.ac.uk>
Cc: W3C OWL Working Group <public-owl-wg@w3.org>
To: Jonathan Rees <jar@creativecommons.org>

There were no trick questions. I don't know fully understand your  
concerns were and so I was trying to get more information.

On 28 Jan 2009, at 14:34, Jonathan Rees wrote:

> On Tue, Jan 27, 2009 at 11:53 AM, Bijan Parsia  
> <bparsia@cs.man.ac.uk> wrote:
>>
>> On 27 Jan 2009, at 15:50, Jonathan Rees wrote:
>>
>>> On Jan 27, 2009, at 4:55 AM, Bijan Parsia wrote:
[snip]
>> 1) If there exists a public domain/open source XSLT translator,  
>> does that
>> assuage your worry (even if not produced/endorse/published by the  
>> working
>> group)?
>
> Yes, if the proposed XSLT has no other complications, such as  
> reference
> to a CGI script.

So, as I understand it, we can, as far as you're concerned, close  
ISSUE-97 with no action:
	http://www.w3.org/2007/OWL/tracker/issues/97

Maybe it wasn't clear...I'm asking if you would be happy if there  
*existed* such an XSLT. Specifically, one not published or endorsed  
by the working group. That is, no where in W3C space.

If so, we could wait until CR.

> This is not an if; as I said XSLT is ubiquitous. There are many.

? The argument about GRDDL is whether we put a specific XSLT at the  
owl namespace URI intended for automatic download and execution by  
GRDDL agents.

> Frank may be of a different opinion. I'm looking for compromises that
> might make you both happy.

I don't know what your compromise list is.

>> 2) If there were (counterfactually again) an OWL/XML to triples  
>> parser for
>> every known RDF or OWL toolkit, would you be happy even if there  
>> was no
>> XSLT?
>
> This is not the situation I'm talking about, so no, this would be  
> irrelevant.

Well, I said "counterfactually" specifically because it's not the  
situation that is, or is what you were talking about. I'm trying to  
figure out your concerns. Some people have argued specifically that  
GRDDL is needed to avoid breaking existing tools. (Of course,  
existing tools often don't have GRDDL support so...I'm at a loss for  
how it helps.)

>> 3) If there were an XSLT published by the working group, would you be
>> satisfied even if it were not (easily) downloadable from the  
>> namespace page?
>
> This sounds like a trick question.

It's not. I sounds like you aren't familiar with GRDDL or this issue.  
Believe me there have been REAMS of discussion on it :)

> I think the answer is yes, but I
> can't imagine why
> under normal conditions it couldn't be downloadable.

*From the namespace page*. I.e., if you dereference "http:// 
www.w3.org/2002/07/owl" do you get this XSLT. I'm very much opposed  
to that. That's the normal case with GRDDL.

> You get it when the
> server can give it to you (just as you get the OWL 2  
> recommendations), and use
> a cached or mirrored version if for whatever reason you need to.

If you are indifferent to where it is published, then we are much  
closer than I am to many GRDDL advocates.

I still wonder why it's the job of the working group to produce or  
endorse this particular piece of software over any other.

>> 4) Do you prefer a frozen, perhaps buggy published XSLT or a  
>> "fragile" XSLT
>> which connects to (several) web services and are maintained? (Note  
>> that
>> several HTML editors connect to the W3Cs HTML validator to provide
>> validation.) (I'm not saying that these are the only options. Just  
>> asking
>> which of these two you prefer.)
>
> Also sounds like a trick question,

It's not, really. That's the *actual* choice, as far as I understand  
it. At least potentially.

> but given this foul choice, I'd say
> the buggy one.

Really. Wow.

> (This is why I suggested it be nonnormative.)

If we publish it at the namespace for auto download by GRDDL  
agents...well I think "nonnormative" doesn't mean much.

If you just want to see such a thing, then I suggest you suggest to  
the working group that it would be a good exit criterion from CR for  
the XML serialization.

But if so, it's a somewhat strange one. Usually, the W3C doesn't  
require specific implementation technologies. For example, there is  
no XSLT based implementation of a GRDDL agent...python, java, and c  
were deemed sufficient.

> Bugs can be fixed in a decentralized way,

Actually, they can't. At least I don't see how.

> and for something
> this straightforward it should be clear how to do so; but servers
> can't be conjured from nothing, and *their* behavior  is completely
> unbankable.

? The code's

> I could ask you the same question about your nominally normative
> XML schema.

I actually don't like that its normative.

> What if you find a bug in it, where it is inconsistent with
> something said elsewhere in the OWL 2 recommendation?

Definitely we need a hierarchy of correctness. Which is a flaw in the  
current document.

I was just thinking about this today.

> Would this
> possibility mean you'd want to suppress the schema from the rec,
> and instead refer readers to a schema-providing server or service?

One key difference is that, in principle, the XML Schema could be  
part of the normative specification of the XML syntax (indeed, that's  
how it is now...it needs a reference to the global restrictions  
before it is complete). The XSLT is, by definition, not a  
specification or an alternative specification but an implementation.

> I would have said: Here is the requirement on the schema, the  
> requirement
> is normative, and to the best of our knowledge the following schema
> meets it, but like everyone else we're fallible, so we have to say  
> this
> schema is only informative.

Again, if the schema is part of the specification, that's like every  
other specification. The XSLT is one implementation of an existing  
specification (the RDF mapping roughly). I don't think we need two  
specifications. Furthermore, no one who's argued for it has asked for  
a non-normative XSLT based specification, they've asked for an  
implementation that is intended to be widely used. I think that's  
fundamentally inappropriate.

[snip]
> I'm sorry but I won't be able to continue this conversation from here,
> as parrying with you is always very time consuming.

I'm sorry you feel that the discussion is adversarial. I am trying to  
get clear on your concerns. I think you have some misconceptions  
about how the debate about GRDDL overall played out.

To be clear, my preference is that the working group not produce or  
publish an XSLT based implementation of the specs. I have no trouble  
in CR calling for such implementations or even working on one myself.  
I would hope that such a transformation, if good, would be pointed to  
from the CR report and various other W3C pages.

The working group's fundamental job is specification, not  
implementation.

> I look forward to
> hearing the
> WG's response to Frank's public comment and may be able to take the  
> subject
> up again at that time.

Ok.

Cheers,
Bijan.
Received on Wednesday, 28 January 2009 15:01:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 28 January 2009 15:01:22 GMT