Re: GRDDL and OWL/XML

Bijan Parsia wrote:
> For the sake of the OWLWG, if the GRDDL discussion group can come to 
> some consensus it believes would be helpful, I'd love to have it 
> brought back over. I prefer the detailed discussion not to be 
> reflected directly back as we have a lot of other stuff on our plates.
>
> Is that ok?
Sounds like a plan. So, shall we test for some consensus?

It appears the 2 reasonable options are:

1) List of implementations at the namespace doc (Bijan)
2) An implementation in XSLT at the namespace doc, with a list of other 
implementations and a warning that the implementation in XSLT is just 
conformant, i.e. not more "normative" than any others.  .

Bijan is bringing up some critiques of 2), and the GRDDL WG members seem 
to agree with Bijan's perceptive and good points that GRDDL does not 
have to be an XSLT or "normative" in the strong sense.

 I think that 2) is a reasonable position that may satisfy some of 
Bijan's concerns about normativitiy - is there any disagreement on that 
from the members of the GRDDL WG, who prefer 1)?

>> Bijan Parsia wrote:
>>>
>>> On May 12, 2008, at 8:55 PM, Dan Connolly wrote:
>> [snip]
>>>>> I feel fine in asking a W3C wg to provide a specification *for the
>>>>> transformation function*, but it should not be the presumption that
>>>>> saying "Support GRDDL" means providing an implementation.
>>>>
>>>> Presumption? It's a straightforward reading of the GRDDL spec, no?
>>>>
>>>> "Developers of transformations should make available 
>>>> representations in
>>>> widely-supported formats. XSLT version 1[XSLT1] is the format most
>>>> widely supported by GRDDL-aware agents as of this writing ... ."
>>>> -- http://www.w3.org/TR/grddl/
>>>
>>> People are reading the SHOULD as a MUST. That's what I object to. My 
>>> straightforward reading of the spec is that it is SHOULD. In any 
>>> case, we supply the transformation in HTML which is way more popular 
>>> than XSLT :) (albeit, not with GRDDL-aware agents).
>> Bijan is right here, it is a *should* - the GRDDL specification does 
>> not specify any programming language in particular, although we 
>> *recommend* XSLT as it is a widely-supported format and the one that 
>> to my knowledge all GRDDL transforms use.
>
> Do we not have a stronger point? Isn't the mere fact of an 
> *implementation* merely a SHOULD? That is, a non-executable 
> specification of a transformation function is sufficient to have a 
> GRDDL spec compliant namespace document (or transformation property in 
> general).
>
> Controlling text:
> """ The general rule for using GRDDL with well-formed XML is:
> If an information resource([WEBARCH], section 2.2) IR is represented 
> by an XML document with an XPath root node R, and R has a GRDDL 
> transformation with a transformation property TP, and TP applied to R 
> gives an RDF Graph[RDFC04] G, then G is a GRDDL result of IR."""
>
> (the second paragraph is in "normative green" :)) Going back to GRDDL 
> transformation definition (oh, and it's confustion to go from 
> Transformation to Transformation Property, presumably TP is a name of 
> the trasnformation, not a property of the transformation.)
>
> ...ok, I can't find the univocal, normative definition of a GRDDL 
> transformation. Section 6  has normative green, but no indication of 
> what is normative in that section and for what. The green rule seems 
> to give sufficient conditions of  being a TP given an xslt expressed 
> transform, but not the converse. This part of the spec seems to 
> interweave normative claims, best practice recommendations, and 
> normative claims given that you want to do some best practice.
The TP is just whatever is at the end of the predicate 
"http://www.w3.org/2003/g/data-view#namespaceTransformation" I believe, 
although this is phrased slightly differently normatively due to the 
great QName->URI issue.

The GRDDL Spec says "a *transformation property*, a function from XPath 
document nodes to RDF graphs". Yes, that's not in green. We decided to 
do rules normatively, and keep the vocabulary informative. We thought it 
would be simpler that way by avoiding "conformance vocabulary" issues - 
i.e. defining normative conformance in terms of possibly vague words 
rather than a few clear rules. However, if the rules are unclear, the 
words should informatively help.

I think it's kinda assumed the transformation property "function" can 
actually execute, although if and when the execution happens is up to 
local policy. Any other opinions on this?
> I don't think turning any of the (perhaps implicit) shoulds into musts 
> is a good idea. If reference implementations turn out to be useful 
> enough, people will produce them naturally. If they don't produce/use 
> them naturally, well, that's a comment on their perceived utility.
>
> In general, I'd prefer a model that allowed and encouraged a clean 
> distinction between specification and (many possible) 
> implementation(s). That seems like a much more robust design, both 
> technically and socially. I'd also prefer that GRDDL encouraged 
> *variant* transformation functions. For example, I might want to GRDDL 
> an approximation of an OWL/XML rather than a faithful translation.
You can have multiple transformation properties. There's nothing in the 
spec against that. The agent can then choose among them. We do want 
faithful translations though, not sure about this "variant" point. We 
assume GRDDL gets one a faithful translation, and then any pruning or 
expanding or other "variance" can then be done later in the pipeline of 
the local agent.

> [snip]
>>> (I certainly wouldn't might pointing to a *set* of implementations 
>>> of our transformation functions, including web services, etc. Then 
>>> the GRDDL agent could ask the user which to use/install/whatever. As 
>>> long as the namespace document is actively maintained, that's not so 
>>> bad, furthermore, it can point to other lists...)
>>
>> However, at the same point, while it makes perfect sense for the W3C 
>> not to specify "reference implementations" per se, after all, the 
>> reference is the specification. However, this does not exclude 
>> conformant implementations. It does make sense for any specification 
>> to have test cases and verify that that there are conformant 
>> implementations.
>
> Sure. I've encouraged (and worked on) an XSLT implementation, as well 
> a Python implementation, of a transformation from OWL/XML to RDF/XML. 
> CR generally requires two interoperable, conforming implementations, 
> preferably independent developed. The demand is that we go further and 
> 1) develop an XSLT implementation as a WG (soliciting someone to do it 
> for us is morally the same as doing it ourselves), 2) produce this 
> implementation *as a deliverable* (whereas CR implementations aren't 
> the WG product...the CR *report* is), and 3) bless this implementation 
> by publishing in an autodiscoverable place in W3 space, in fact, a 
> place that is closely associated with OWL per se. These do not seem 
> like sensible things to demand of a WG, particularly one concerned 
> with specification.
That's your issues with whoever is making those 3 demands, which 
certainly isn't us, and I agree with you that in particular, 2 seems a 
bit harsh to me. However, I do see no reason why if an conformant XSLT 
is produced, to not put it at the namespace doc for those unlucky enough 
not to use a conformant OWL2 implementation with the function local.
>> I assume OWL2 will (not sure?) have test-cases and conformant 
>> implementations for its XML->RDF mapping. If one of those conformant 
>> implementations happened to be implemented in XSLT, I think it would 
>> make good sense for it to be available as a GRDDL from the namespace 
>> doc of OWL 2.
>
> My impression is that "available" means "explicitly and univocally 
> available as a auto, typically without user intervention, loaded piece 
> of code promised to be complete with commitment from the W3C on future 
> maintenance". We've proposed adding a pointer to the CR report and 
> this was rejected as violating the GRDDL spec (though, now, people 
> are, I hope, moving to the more reasonable claim that it violates 
> GRDDL *culture*).
Your argument is that the CR report specifies the function abstractly. 
I'm pretty sure the GRDDL WG was not thinking of non-executable 
functions when developing GRDDL. I would like to here other opinions of 
whether or not a GRDDL transformation has to be "executable."

My personal opinion is that I am not sure what the utility of it is if 
it can't be executable, although the namespace doc should give proper 
warnings via maintenance, normativity, etc. The list of non-executable 
functions and the spec would seemingly be better connected to the 
namespace doc via RDDL, no [1]?

> So, I do not believe it makes good sense to do this, esp. given the 
> prevalence of high quality implementations that are widely used by the 
> OWL community already.
>
> BTW, I expect people to *extend* the OWL/XML syntax in a variety of 
> ways...I'm very unclear how that interacts with a fixed GRDDL 
> transformation and esp. an implementation.
>
>> Has anyone tried this? I would not encourage them, but again, would 
>> encourage someone to do an OWL2->RDF XSLT and see if it can be made 
>> conformant.
>
> I hope you see why the correctness of the XSLT is not the only issue.
>
>>> Cheers,
>>> Bijan.
>>>
>> P.S.:
>> Obviously, caching should be done to prevent the issues brought up by 
>> Henri.
>
> It's not caching alone. DTDs typically don't express all or even most 
> of the constraints of an XML format. So too for XML schema (wsdl is a 
> great example there). Obviously XSLT is more expressive, but then we 
> get *very* far from a straightfoward specing.
>
>> The caching issues should not be a reason to not use GRDDL. The GRDDL 
>> specification does not tell implementers how to cache, but it is 
>> given as something GRDDL-aware agents should do: "GRDDL-aware agents 
>> therefore should not retrieve such documents on every reference and 
>> should retain some cache or local memory of the transformations those 
>> documents indicate should be applied." [1].
>
> Given that Henri, obviously, is well aware of caching possibilities, I 
> think caching is not really a solution. I don't see that it's a great 
> burden on users to configure their GRDDL agent for the well known 
> namespaces and the GRDDL vendors can compete on the quality of those 
> plugins as can third parties working in XSLT. I really don't see a 
> development/deployment advantage *other than* monopoly favor for the 
> blessed implementation. (Whether the monopoly play succeeds is a 
> different matter. However, I think monopoly plays are very bad PR.)
Hopefully users to configure their GRDDL-aware agent to use local 
alternatives. But what about those that don't?

A default is better than none IMHO. Ideally, vendors can a and should 
compete for XML to RDF transforms, but for many vocabularies less 
popular than OWL2 having a *single* transform to RDF is often not 
possible. GRDDL encourages at least one, but preferably multiple, 
transforms.
> As I said before, there are good cases for web discovered, autoloading 
> cases, e.g., when it's ad hoc or for very small minority communities, 
> etc. But that's not our case. By encouraging a community to demand 
> that namespace document owners provide this kind of reference (and not 
> just reference...deployed default!) implementation, I predict that 
> that community will engender ill will. This is already true in the OWL 
> case. My early perception (as a veteren of the WSDL (and similar) 
> debacles) of GRDDL was positive because I thought the intent was to 
> encourage very non-intrusive behavior. And, for sure, it's better than 
> demanding (or requesting) that everything be done in RDF (or bemoaning 
> when it's not), but it still has a long way to go.
No one here is making demands, we're just trying to clarify GRDDL. "Ill 
will" seems strong to me. In fact, I think RDF sort of people who are 
unlucky enough not to have a locally installed OWL2->RDF transform may 
find it actually useful, and those that do have another locally 
transform or do not use RDF will just ignore GRDDL. Those that do not 
have a locally installed OWL2->RDF transform may be a small, minority 
community. However, by not providing them an easy way to get RDF out of 
XML via an XSLT (i.e. GRDDL), that could provoke ill will towards OWL2 
in some of the RDF community, no?

I still do not see a good case on how a GRDDL transform (or multiple) 
that are actually executable hurt people, except if they perhaps *make* 
the mistake that the GRDDL transform is somehow "more normative" than 
others. But that's psychology, and the namespace doc can add a paragraph 
making it clear and a pointer to other conformant transforms that 
perhaps must be installed locally and are not compatible with current 
GRDDL-aware agents.

Hope this helps.
> Cheers,
> Bijan.
>
> Cheers,
> Bijan.
[1] http://www.rddl.org/

Received on Tuesday, 13 May 2008 13:55:27 UTC