W3C home > Mailing lists > Public > public-grddl-wg@w3.org > November 2006

Re: GRDDL Spec Review (editor's draft Date: 2006/11/16 14:17:13)

From: Chimezie Ogbuji <ogbujic@bio.ri.ccf.org>
Date: Wed, 22 Nov 2006 10:51:52 -0500 (EST)
To: public-grddl-wg <public-grddl-wg@w3.org>
Message-ID: <Pine.GSO.4.60.0611221041010.18551@joplin.bio.ri.ccf.org>

On Wed, 22 Nov 2006, Dan Connolly wrote:
>> "The use of XSLT to generate XHTML (...)"
>> I find this sentence useless in the context of this spec and it sounds
>> "gratuitous" to me in the sense that nothing in this context is related
>> or backing-up this claim. IMHO of non native speaker, its phrasing is
>> not really in the style I would expect in a spec.

I'm not sure how you backup a well-known paradigm with people who use XSLT 
- refer to a blog posting or book?  I don't think it's gratuitous at all, 
the role that XSLT plays in both generating XHTML and generating RDF (for 
GRDDL) is very closely related, that's the point of this section.

>> "separating structured content from its authoritative meaning (or
>> semantics)"
>> I don't follow this sentence:
>> A - whereas the migration from just HTML to XML+XSLT+XHTML+CSS did shift
>> the initial HTML representation to a separated representation (XML) +
>> XSLT + (XHTML + CSS) the GRDDL proposal does not change the initial
>> representation dialect;

Though GRDDL does not change the initial dialect, a GRDDL transformatin 
*is* a clear, distinct seperation of structured content from 'RDF that 
preserves the original meaning of the document'.  I don't see how this 
senetence is incorrect.

>> B - XHTML is itself a source for GRDDL and I find it confusing to say
>> that GRDDL separates the content from its meaning while the
>> representation remains XHTML.

See above

>> C - separating content from authoritative meaning sounds odd when one of
>> the point I heard several times in the GRDDL group is that the GRDDL way
>> to explicitly specify the transformation in the source actually ensures
>> that the extracted RDF will have the meaning specified by the
>> authoritative source of the structured content;

How is this different from seperating content from authoritative meaning? 
The meaning is embedded in the structure, GRDDL provides a way to extract 
it - a clear seperation between the structure and the meaning (the 
abstract RDF parsed from the GRDDL result).  There *is* a distinct 
seperation as the embedded RDF has no value until it has been extracted 
and parsed.

>> in other words to me,
>> this sentence makes GDDL sound like scrapping which I would personally
>> like to be addressed in GRDDL but which I also now know not to be in the
>> scope of GRDDL.

GRDDL *is* scrapping.  There is a stigma associated with screen scraping 
because we tend to think about javascript, but in reality that is just 
another way of scrapping RDF from structured content.  Scrapping and 
gleaning are synonymous.  What exactly is the difference?

> Yes, that does seems sorta backwards. I tried to reword it a bit
> but ended up just striking a couple sentences, leaving:
>
> <p>GRDDL is a mechanism for <b>G</b>leaning <b>R</b>esource
> <b>D</b>escriptions from <b>D</b>ialects of <b>L</b>anguages.  That
> is, GRDDL provides a relatively inexpensive mechanism for
> bootstrapping RDF content from uniform XML dialects; shifting the
> burden from formulating RDF to creating <a
> href="#txforms">transformation algorithms</a> specifically for each
> dialect. GRDDL works by associating transformations for an
> individual document, either through direct inclusion of references or
> indirectly through profile and namespace documents. Content authors
> can nominate the transformations for producing RDF from their content
> and use GRDDL to refer to them. </p>
>

This doesn't say anything substantive about what is quite unique to GRDDL: 
it's a method for managing / seperating structured 
vocabularies and their interpretations.  What you have left is about 
as useful as the acronym by itself (not very).

Chimezie Ogbuji
Lead Systems Analyst
Thoracic and Cardiovascular Surgery
Cleveland Clinic Foundation
9500 Euclid Avenue/ W26
Cleveland, Ohio 44195
Office: (216)444-8593
ogbujic@ccf.org
Received on Wednesday, 22 November 2006 15:52:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:11:46 GMT