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

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.


>
>> In a nutshell, the use-case - assuming you think having RDF is useful 
>> - for GRDDL is that the GRDDL-aware agent, which can process RDF, may 
>> *not* have a local transformation for OWL 2, and therefore goes to 
>> the namespace document or follows a GRDDL link and downloads (using 
>> caching) a transformation (usually XSLT) to get out OWL 2 XML to RDF. 
>> This is necessarily not "silent and automatic" as the GRDDL-aware 
>> agent often has to explicitly enable GRDDL.
>
> I have some trouble with the "necessarily" and the "often, but ok. 
> There's no inherent reason for preferring the namespace document then, 
> I presume. If I have some other repository, that's ok?
The namespace document is preferred for documents where the namespace 
document can be accessed, since it is easier since the GRDDL-aware agent 
"follows its nose" there, otherwise you have to expect instance data 
authors to put this in the header of the XML:

  xmlns:grddl="http://www.w3.org/2003/g/data-view#"
  grddl:transformation="owl2toRDFexample.xsl"

>> *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.


>> If Bijan does not believe that is the case, that's fine - and so I 
>> think no additional commentary is needed on my part, although I hope 
>> others continue to help Bijan.
>
> Thanks for you help!
>
>> However, I would recommend that one does be clear that the objection 
>> to the GRDDL transformation is based on believing the above-mentioned 
>> scenario is not worthwhile, not on an idiosyncratic reading of the spec.
>
> ? First, I think my reading is straightforward from the text. Second, 
> I actually believe there is value in speccing a GRDDL transform 
> without supplying an XSLT. But if that's not a position anyone else 
> likes I'll definitely not push it.
>

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.
The issue with GRDDL is that it's not really human readable, while the 
speccing and list I assume are.

>>   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 :)

 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, 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.




>>>> I could implemented an OWL-reasoner by writing it down an algorithm 
>>>> and then publishing it in HTML,
>>>> would this count as an implementation? I think the answer would 
>>>> tend to be "no."
>>>
>>> I thought the GRDDL implementation was, y'know, the GRDDL agent. 
>>> I'm  not suggesting that people download non-executable GRDDL agents.
>> The GRDDL agent executes the transform, but it can not retrieve the 
>> transforms from a list,
>
> Yeeees, but this presumes that it must. Which goes back to the 
> original scenario, I guess.
>
>> although Norm Gray's solution of having different transforms with 
>> different media types with multiple GRDDL links does make sense, if 
>> GRDDL-aware agents start using, say Javascript, as opposed to XSLT.
>>
>> Just as an OWL reasoner reasons over OWL 2, a GRDDL-aware agent 
>> executes a GRDDL transform.
>
> I guess I should stop for the sake of all. :) It's clear that y'alls 
> *intent* was that things were executable and that they were retrievable.
>
>> A spec list is not executable.  Just as an OWL reasoner written in 
>> HTML could not reason with an OWL ontology given by in OWL 2 XML, or 
>> one would not expect an actual OWL2 reasoner to reason over "OWL2 
>> ontology" made in say, a UML authoring tool, so we would not expect a 
>> GRDDL aware agent to execute or do anything useful with just a HTML 
>> file at the end of a GRDDL transformation predicate. A human could, 
>> which is why a RDDL link is preferable to a GRDDL one for the spec list.
>
> Ok, that's a delineation, for sure. So if we had such a RDDL document, 
> what would you expect GRDDL agents to do? If we don't give a GRDDL 
> document (with executable), can GRDDL agents users appeal to anything 
> other than usefulness (which seems sufficient) to encourage a GRDDL 
> agent author to include a transform?

See above.
> [snip]
>>> *An* executable, not a silently auto-downloadable one.
>>
>> As I have stated about five times before, it does not have to 
>> "silently, auto-downloadable." Local policy could enable the 
>> download, and in fact, most GRDDL implementations seem to be able to 
>> turn GRDDL "off and on" with command-line options.
>
> Forgive me for being dense, but then why does a namespace author have 
> to (ought to?) supply a transform? I mean, is it *just* convenience? 
> If so, why are people so hard for it?

>> Furthermore, if a locally installed transform was available, GRDDL 
>> would probably not be used.
>
> 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.


See definition of GRDDL Transformation" in Section 2 of the spec.

 "Given an XPath[XPATH] <http://www.w3.org/TR/grddl/#XPATH> root node N 
with root element E, if the expression

/*/@*[local-name()="transformation"
  and namespace-uri()=
    "http://www.w3.org/2003/g/data-view#"]

matches an attribute of an element E, then for each space-separated 
token <http://www.w3.org/TR/grddl/#stok> REF in the value of that 
attribute, the resource identified[WEBARCH] 
<http://www.w3.org/TR/grddl/#WEBARCH> by the absolute form (see section 
5.2 Relative Resolution in [RFC3986] 
<http://www.w3.org/TR/grddl/#rfc3986>) of REF with respect to the base 
IRI[RFC3987] <http://www.w3.org/TR/grddl/#rfc3987>,[XMLBASE] 
<http://www.w3.org/TR/grddl/#XMLBASE> of E is a GRDDL transformation of N.

>>>> That's a use-case that I have yet to see an argument against that 
>>>> caching and warnings about normativity would not address.
>>>
>>> That's not a use case, that's a deployment scenario. You start with 
>>> the presumption that GRDDL-enabled agents will not bundle transforms.
>>>
>>> After all, they don't need to *DO* the coding themselves! Someone 
>>> can write a free XSLT transform and the GRDDL agent author can 
>>> download it.
>>
>> But where from? The obvious place is the namespace document for GRDDL.
>
> 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.

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


>>>>> From a marketing perspective, it feels like a bait and switch. I 
>>>>> feel like I did due diligence and now am sandbagged. Proper specs 
>>>>> *cannot* require people to interview members of the community to 
>>>>> determine what conforming behavior is. That defeats the point!
>>>> No-one else in the community has ever brought up the point that the 
>>>> GRDDL transformation could be non-executable.
>>>
>>> This is a weakness on your part, not a strength. It's a 
>>> straightforward reading of the spec.
>>>
>>> Part of the point of specs is to codify *in the spec* the 
>>> understanding.
>>
>> It could also be an idiosyncratic reading of the spec
>
> I guess. I don't feel like I had to do a lot reading in, but <shrug>, 
> I am only one data point. The fact that the editor (dan) and some of 
> the interlocutors (e.g., Chimezie) disagree about this suggests that 
> it's not so very idiosyncratic (at the least, it's unclear what's 
> *actually* required).
>
>> whose use cases I have consistently would be better served by 
>> human-readable explanation at the namespace document and serving a 
>> RDDL file with links to other implementations.
>>
>>> One thing I'm trying to convey is that I thought I *was* part of the 
>>> GRDDL community, broadly construed. But I guess I'm not and people 
>>> with my sorts of concerns and perspectives are not. (That's fine! 
>>> Nothing morally wrong with that. Just be aware that it limits 
>>> adoption.)
>>
>> We are all part of the community, both GRDDL and wider Semantic Web 
>> community, and trying to understand each other's needs I hope!
>
> It's unclear to me. I confess that I am disappointed because I thought 
> GRDDL was part of a smarter strategy for dealing with the broader web 
> (unlike, say, RSS 1.0 or WSDL's RDF mapping). But it doesn't seem that 
> way. By coupling and conflating spec, implementation, and a rather 
> strange distribution requirement *so tightly* I think we're still too 
> close to the "Put everything in RDF" days. The use case document 
> doesn't really help because it starts from the premise that the best 
> way to accomplish all those use cases is to get it into RDF and use 
> RDF tools. As you well know, this is not universally shared. Mash-up 
> and microformats folks don't give two tosses for RDF afaict and 
> neither required namespace based anything.
>
> Oh well.

It's purpose is to make it easy for XML and microformat 
authors/consumers to get RDF. Whether that is smart or not is a matter 
of opinion :)

 
>>>> Thus, I think your reading of the specification is unique. I am 
>>>> glad you have brought this up, as no-one has thought this through 
>>>> before, and it is an intelligent if unusual point.
>>>>
>>>> I think if you or others do not want an executable GRDDL 
>>>> transformation, or object to a RDF translation of OWL2/XML to RDF, 
>>>> that's fine. It is clear you believe an executable GRDDL is 
>>>> unnecessary or harmful and there is no reason to address 
>>>> RDF-consuming agents that may not have OWL2XML local transforms. I 
>>>> would be interested if other members of the OWL2 WG also think this 
>>>> is the case.
>>>
>>> Some do, some do not. I'm still unclear why this is a *use* case.
>>
>> See first point.
>
> 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.

You can not easily "merge" microformat data. 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]

 Same re FOAF and "Data Portability" using XFN, see Social Graph API 
from Google [3]. While it doesn't use GRDDL per se, the general idea 
that data should be converted on the fly to RDF works.

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.

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.


[1]http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html
[2]http://www.w3.org/TR/grddl-primer/#hotel
[3] http://code.google.com/apis/socialgraph/



> Cheers,
> Bijan.

Received on Tuesday, 20 May 2008 16:41:33 UTC