Re: Not GRDDL, but GRDDL-like (was Re: GRDDL and OWL/XML)

On 20 May 2008, at 17:40, Harry Halpin wrote:

>
> Bijan Parsia wrote:
>> On 20 May 2008, at 15:01, Harry Halpin wrote:
>>
>>> Bijan Parsia wrote:
>>>> On 20 May 2008, at 00:37, Harry Halpin wrote:
>>>>
>>> To address your worries, Bijan,  having an XSLT tranform  
>>> available as a GRDDL transform *does not force* the GRDDL-aware  
>>> agent to use the XSLT transform if a better or preferred  
>>> alternative is available to the client locally. Period.
>>
>> That's something. Could you point to the controlling text of the  
>> spec?
>
> I hope this helps, in Section 7. There's an example to help:
>
>
> "For example, a SPARQL query service might use a GRDDL-aware agent  
> for collecting RDF data. The appropriate policy, for which results  
> to compute and when, is likely to involve waiting for a signal from  
> user more in the Web browser case than in the query service case."
>
> In normative "green" :
>
> "Subject to security considerations below and local policy as  
> expressed in its configuration, given an information resource IR,  
> and an XPath node N for a representation of IR, a GRDDL-aware agent  
> should: "
>
> Reading down, you might want to note the paragraph, emphasis on  
> "selectively apply":
>
> "Selectively apply any or all discovered transformations to obtain  
> GRDDL results. Note selection may be guided by the agent's  
> capabilities, local security policies and possibly user/client  
> intervention.
[snip]

Thanks Harry! Much obliged!

>>> *In this case*, I believe the benefit of having an XSLT available  
>>> for the agent outweighs the costs that have brought up.
>>
>> Please remember that I believe that there is a benefit here for  
>> cases I call "semantic stylesheets", that is, cases where the  
>> format and the transformation are not widely known.
>
> That is where GRDDL does work best, I agree! Since OWL2 is likely  
> to be an important Web standard, I find it more likely that RDF- 
> based SemWeb libraries will have local transforms for it to RDF  
> rather than use GRDDL. But, some may not, and for those, the XSLT  
> could help.

Ok. That's not unreasonable. I think I prefer to be cautious here  
where you prefer to be braver, esp. given the likely corner caseness  
of this scenario.

[snip]
> I think there's value in all transforms as well, GRDDL and  
> otherwise. I'd *definitely* link the transformation to the  
> namespace doc using RDDL.

Ok, so you believe that what I propose to do should be done via RDDL  
instead of GRDDL. I presume this means that specifying a  
transformation property is not worth doing without the executable?

> The issue with GRDDL is that it's not really human readable, while  
> the speccing and list I assume are.

Ok. How would the OWL WG encourage GRDDL agent authors to include the  
transform *without* providing an executable? Is there any sense to  
this at all?

>>>   And having as many transforms, including locally installed ones  
>>> that may be preferable to an XSLT one, are great for OWL 2 and  
>>> the entire SemWeb.
>>>
>>> If this is an issue with the charter requiring a GRDDL  
>>> transformation this should be brought up with whoever wrote the  
>>> charter.
>>
>> Well, the point is that I based a decision about the charter on  
>> that, what is now labeled, idiosyncratic reading of the spec. This  
>> seems to be a spec and advertising problem. Perhaps no one else  
>> will ever read the text that way (though I'd be surprised; it  
>> seems pretty straightforward).
>
> If we get any more complaints about the spec in this manner, we'll  
> definitely put it in the errata for the next version (if there is  
> one of GRDDL.) My main complaint about the spec is that the  
> pictures aren't better :)

:)

>>> [snip]
>>>>> Linking to a list of implementations from the namespace  
>>>>> document using RDDL would be useful though. And having links to  
>>>>> multiple types of transforms (distinguished by media types as  
>>>>> mentioned by Norman Gray) could be useful as well. What is the  
>>>>> use-case of a non-executable GRDDL transformaton?
>>>>
>>>> To spec what a GRDDL agent should do when encountering that  
>>>> namespace. In the OWL case, of course, it was already obvious,  
>>>> but in other cases it may not be.
>>>
>>> But that spec would be human-readable list? It seems that would  
>>> be better connected via RDDL.
>>
>> How does RDDL instruct GRDDL agents (and authors thereof)?
>
> It doesn't, but allows humans to easily follow their nose on the  
> namespace doc. Also, RDDL is also GRDDL'able. See "Self-Describing  
> Web" TAG finding for full explanation [1], although I'm sure given  
> previous comments that you may think this is the Webarch crazy pill :)

Well, yes :) This raises the interesting question of how people who  
believe in Web Architecture [TagM] and those who don't can usefully  
communicate and come to consensus. Obviously, appeals to WA don't  
help :)

> So one could imagine user agents possibly figuring out from  
> GRDDL'ing the RDDL document, getting a machine-readable list of  
> implementations and figuring out from that which one is suitable  
> and then recommending the user download one.
>
> I do think there is a principle disagreement here about self- 
> description between you, Hixie, and others versus people who think  
> self-description is a good part of Web arch,

Or a part of the web at all...

> but I was trying to argue that since GRDDL agents don't *force*  
> anyone to use the XSLT, it couldn't hurt too much to have a GRDDL  
> transform and could help.

Yep. There is a problem between local and global argument. If it's  
"harmless" here but helps the "GRDDL juggernaut" (esp. since from the  
start I keep getting "You should have raised it earlier" and "that's  
the way GRDDL is" discussion ending line I've heard a lot :)), then I  
have a reason to oppose it. Not the kind of reason I *like* to have,  
obviously.

[snip]
>> GRDDL *includes* the downloading? I mean, I'm not using GRDDL if I  
>> don't download (but maybe if I cached, but not if I have a local  
>> install)?
>>
>> I'm very confused.
>
> Going on just the XML case, the spec says that GRDDL does involve  
> the root node having a "http://www.w3.org/2003/g/data- 
> view#transformation" predicate, right?
>
> It was expected that agents should cache them if they use a  
> transform a lot. A local install could point that predicate to a  
> file:// URI to make a locally-installed transform a "GRDDL  
> Transformation" though not sure what one gets.
[snip]

or one could use a URN, to be pedantic.

[snip]
>> Well, I don't think people have such a hard time finding code.  
>> Google and spelunking around the OWL web pages should be  
>> sufficient, yeah? And that's what they'll have to do anyway if the  
>> namespaced transform executable is poor quality or otherwise  
>> inappropriate.
>
> The idea was to make it semi-automatic, i.e.  automatic if the user  
> specifies they want to run either all GRDDLs or specific GRDDLs  
> they want on a per instance basis. Kinda like "firefox plug-ins" to  
> get RDF. You don't Google for it or go to the mozilla homepage.

I'm missing something. I feel like I surely *would* google or go to  
the mozilla page to find a firefox plugin. Or you mean to invoke the  
transform in a particular case? Ah, yes, sure. But that's consistent  
with a first query to *install* the plugin in, yes?

> And yep, sometimes the user may want to get a better transform.

Ok.

[snip]
>> I guess I still wonder what makes GRDDL unique in this respect.  
>> I.e., what's the failure e.g., with the microformats strategy? Or  
>> the browser strategy?
>
> GRDDL is not the solution to world hunger, but we thought it was a  
> simple and low-budget idea with minimal harm and possible gain in  
> helping people get data to RDF.

So I thought. But we have different valuations on namespace documents  
and WG produced code. I don't think my valuations are very  
idiosyncratic, though, clearly from this group!, they are not  
universal, of course.

> You can not easily "merge" microformat data.

I don't want to move over into a discussion about RDF merits :) but  
obviously what's easy or hard about merging data is very much case  
and skill and infrastructure and task specific.

> Some people in the microformat community recognize this, and  
> there's a lot of talk about it, albeit not shockingly not a huge  
> uptake on RDF as "the solution" although some people do argue that  
> way.
>
> See use case in Primer for merging microformat data from diverse  
> sources [2]

That's a backend argument, yes? I mean, you could take one of the  
"consume all microformat" tools and use that to translate them into  
RDF. That seems to be a much lighterweight and effective way to  
evangalize (well, and building useful applications on that backend).
[snip]

> What GRDDL needs is more transforms, and the main problem right now  
> is not actually transforms, but lack of stable mapping from  
> microformats to RDF.

I would take care not to spoil the barrel in all this. Obviously,  
GRDDL per se is not the goal, but merely a means. Clearly some  
aspects are going to raise hackles (I can see this debate happening  
with microformats folks pretty easily, actually; there it would be  
*very* hard to avoid giving the impression that the SemWeb guys were  
trying to grab onto microformats to boost their own fortunes when  
they couldn't succeed on their own merits).

> Hope this helps the OWL 2 WG, and I only wish we had this  
> conversation before Spec hit Rec status. Perhaps one day all W3C  
> Specs will be on wikis.

As I age, I don't place as much value on the frozenness of specs. :)  
At least at the meta-level. I still tend to cling to them a bit,  
especially ones I contribute to. But presumably no one would trade  
broad success for fidelity to the spec, or the spirit of the spec.

(I wish I had pushed this with RDF/XML a loooong time ago :))

Cheers,
Bijan.

Received on Tuesday, 20 May 2008 17:50:21 UTC