Re: Practical relevance (e.g., Re: GRDDL and OWL/XML)

On 20 May 2008, at 12:09, Harry Halpin wrote:

> Bijan - again, it's pretty clear with movement by Yahoo!  and the  
> rapid spread of microformats like XFN

My understanding of microformats is that there is no  
autodiscoverable, silently downloaded code. In fact, a brief perusal  
of microformats.org shows quite the contrary, e.g.,:
	http://code.google.com/p/aump/
	http://microformatique.com/optimus/

> that GRDDL-like mechanisms are taking off.

Only if you conflate GRDDL with the software deployment you favor.

> Of course, Yahoo are using their own mechanisms and not GRDDL per  
> se. However, having quick, auto-discoverable and easy ways to get  
> RDF out of certain XML formats is useful for people or clients that  
> do not want to locally code transforms for every vocabulary they  
> might encounter.

So, first, that's not what I argued. I argued that well known formats  
should be supported. Ad hoc ones are potentially different. Second,  
no one says that a particular client or person has to do the coding,  
just that it's not autodownloadable. I'm unclear why in only this  
case, having to fetch or authorize a plugin is such a horrific burden  
that it requires all this. FireFox does just fine with you having to  
install stuff even, gasp, for microformats.

> I would look at Brian Suda's successful use of getting iCal and  
> vCards out of microformats as a good use of how GRDDL could work in  
> the future [1].

503.

> The concrete use-case for GRDDL is rather simple. There might be  
> GRDDL-aware RDF-enabled clients that do not natively transform OWL2.

This isn't a *use case*!

> If so, at least one GRDDL transform in a widely deployed format  
> like XSLT helps them. If you do not think that is likely, that's fine.

I've never argued against XSLT as an implementation platform, merely  
the stuffing of it in autodiscovery etc. There's a perfectly healthy  
implementosphere, why centralize and standardize a *distribution*  
mechanism?

Seriously, how common and significant is this for *any* format from  
the W3C?

> However, that is just a difference of opinion between us at this  
> point, and again, the OWL2 WG should decide as a whole.
>
> I am glad that the argument has moved away from the idea of having  
> a non-executable GRDDL to use-cases, and there is a use-case  
> document that you may want to look at  [1]. Again, as GRDDL  
> transform link in RDF in the namespace doc are not human-readable,  
> there's as much sense there as counting an OWL2 reasoner an  
> algorithm "implemented" in an academic paper available only in PDF.

I really think this is a non sequitur. There are three things that  
get conflated in these debates:
	1) implementation
	2) specification
	3) distribution mechanism

If we were to follow your analogy then the OWL working group should  
provide an OWL reasoner implementation (in XSLT) for auto download at  
the namespace document. Come on!

> t would make sense to have a human+machine readable link to all  
> implementations from the namespace document using RDDL. I do not  
> see any use case for a non-executable machine-readable link.

If I look at the resolution mechanism, I see a GRDDL property as a  
*key*, dare I say it, an *identifier* for a transformation. How it  
*finds* the code for that function is a totally different issue.

> That argument does appear to be odd to me and many others, moreso  
> than the use-case outlined above for GRDDL.

Well, it'd be helpful if you who find it odd would explain why the  
web and microformats community gets by without such a thing and  RDF  
and semantic web does not.

> Bijan Parsia wrote:
>>
>> It would be good to have an answer to:
>>     http://lists.w3.org/Archives/Public/public-html/2008May/0102.html
>>
>> """In practice it isn't at all clear that GRDDL is in any way  
>> relevant in the
>> real world (much like almost anything related to RDF), and so it  
>> isn't
>> really an important concern for the development of the HTML  
>> language."""
> Again, see movement by Yahoo. Some people are interested in RDF. If  
> HTML 5 has a XML serialization (which it will) then it will be much  
> easier to "GRDDL" out of existing HTML 5. It's a chicken and egg  
> problem.

Thus there is no immediate, local use. There's only promises if  
everyone would just get on board it'd be cool.
[snip]

>> AUTHORING
>> I've heard in the OWL case, for example, that OWL/XML risks  
>> shutting out legacy tools that only consume RDF/XML. But first,  
>> they don't seem to be GRDDL sensitive anyway (e.g., Protege3.x).  
>> Second, there are plenty of ways to get RDF/XML from OWL/XML that  
>> are easily discoverable (e.g., <http://owl.cs.manchester.ac.uk/ 
>> converter/restful.jsp>). It seems like users of legacy OWL tools  
>> have *plenty* of mechanisms to work with OWL/XML.
> Why is that easily discoverable by the end-user?

Uhm. Google?

> A GRDDL transformation is equally easily discoverable.

Equally is good enough, then, yes? That makes you lose, not win.

>> SPIDERING
>> Ok, let me try another: semantic web spiders (swoogle etc.). If  
>> there's GRDDL available they'll be able to scrape more and more  
>> easily.
>>
>> But this *also* seems strange. If I'm a spider author, I'm going  
>> to make damn sure that my translations are robust (or I'm just  
>> writing a toy and it seems catering for toy tools is very  
>> strange). So what I want is the clearest possible specification of  
>> the translation. This will almost surely not be an XSLT (for  
>> example) except in the simplests of cases. (And qua spec, a pdf of  
>> the XSLT is fine.) I mean, however does Google *manage* being able  
>> to search Word docs and PDFs and so on without GRDDL like  
>> translations available for them to download?
>
> Again, GRDDL does not mandate XSLTs and other types of executables  
> are possible. If one did not have a *finite* number of  
> vocabularies, but just wanted to scrape as much RDF as possible,  
> then GRDDL could be used.

It's unclear that you'd get much more with GRDDL. After all, you can  
always write a transform for things for which there is no transform.  
And you run before the cart....it's not like this is a massive  
problem requiring this solution. YAGNI seems to apply very strongly  
for GRDDL. Your chicken and egg line supports that.

>> BROWSING
>> Ok, here's a final scenario, suppose I have a generic RDF web  
>> browser, call it Fabulator. To be, in abstracto, maximally useful  
>> it needs to be able to get maximal amounts of RDF from sources  
>> (let's suppose). So, autoGRDDL helps, yes?
>>
>> This seems almost plausible, though not for the OWL case (since  
>> that's well known and all the arguments in spidering apply), but  
>> again, if we look at the web, we see no autoloading, but always  
>> with user intervention, typically directed back to the *browser  
>> author* site, not to the namespace.
>
> See spidering argument.

? You gave no argument.

>> I do see a use for having a "GRDDL" tool, that is, something that  
>> can scrape various formats (but not just XML? see the first part  
>> of Hixie's email) to RDF *for the RDF person*. (And sometimes, I  
>> am that person!) And I'd like format authors, when it's  
>> reasonable, or at least, format communities, to provide a  
>> preferred way of doing the translation *so I can update my tool*.  
>> I don't want to *force* them to spec it "on spec" so to speak  
>> (e.g., how many people *pay* for RDF functionality, either in cash  
>> or in fame and fortune and connections?), but it seems like one  
>> could be judicious and friendly about it.
>
> Again, GRDDL can be enabled or disabled by local policy, i.e.  
> command-line settings, etc. Again, the idea behind GRDDL is to get  
> RDF out of commonly deployed formats. We do hope that OWL2 XML  
> would be one of the commonly deployed format.

This is incoherent. Your spidering line (it's not yet an argument!)  
said something about finite list of formats *not* being the GRDDL use  
case. But now, we have that the idea behind GRDDL is to get rdf out  
of *commonly* deployed formats,w hcih is surely a managable list  
(see, oh, web browsers).

Cheers,
Bijan.

Received on Tuesday, 20 May 2008 11:40:11 UTC