Re: GRDDL and powder

Booth, David (HP Software - Boston) wrote:

> http://www.w3.org/TR/rdf-syntax-grammar/#start
> 
>         "If the content is known to be RDF/XML by context, such
>         as when RDF/XML is embedded inside other XML content,
>         then the grammar can either start at Element Event
>         RDF . . . or at production nodeElementList . . . ."

FWIW, I was looking at the previous para
[[
If the RDF/XML is a standalone XML document (identified by presentation 
as an application/rdf+xml RDF MIME type object, or by some other means) 
then the grammar may start with production doc or production nodeElement.
]]

> 
> But the RDF/XML + GRDDL approach feels more like it is doing the opposite: 
 > embedding some special XML in an otherwise RDF document.  However I 
guess it depends on whether the document as a whole is served as 
application/rdf+xml or application/xml (with a non-RDF root namespace). 
  If it is served as application/xml with a POWDER namespace, then it 
looks fine to me, because the document as a whole is clearly *not* 
RDF/XML (even though it may happen to contain some embedded RDF/XML) and 
its semantics are entirely determined by the POWDER spec, which is free 
to delegate to the RDF/XML spec to define the semantics of the embedded 
RDF/XML portion.
> 
> I *do* think the extensibilty of being able to add arbitrary RDF metadata would be a good thing, and I did not include that in the XML + GRDDL approach I previously suggested, but it would be easy to extend it to do so.  For example, a POWDER document might be served as application/xml and look something like:
> 
> <powder:powder ... >
>   <powder:lite>
>     [Standard POWDER Lite goes here]
>   </powder:lite>
>   <powder:additionalMetadata>
>     [Any additional unconstrained RDF/XML goes here]
>   </powder:additionalMetadata>
> </powder:powder>
> 

That's quite a nice design, working with the para of RDF SYntax that you 
quoted and a node-elemnt list. I'll try and add that to the list of 
possibilities. I think the POWDER WG are likely to make a choice at 
their f2f meeting end of next week.

[Jeremy:]
>> Note that because of the complicated nature of the formal
>> meaning, the GRDDL result is more complicated than the original
>> document, and in my preferred design, in which the original
>> document is in RDF/XML the GRDDL result is not entailed by it -
>> but is a faithful rendition of the intent of a powder document
>> author - who is principly guided by the operational semantics.
> 

> In that case I think it is important that the document be served as application/xml with 
 > a POWDER root namespace, instead of application/xml+rdf.
>

I am not sure why you think this important.
I would think it important not to suggest creating a large class of 
RDF/XML document that were false, when read as RDF/XML - and if you 
really have to, to try and work out how to make it clear to everyone 
that they are false. But the whole idea of the design is that they are 
correct as RDF/XML, and the GRDDL result is also correct.

This seems to be one of the design goals of GRDDL - a document may have 
multiple GRDDL results, each one of which should be a faithful 
rendition, and there is no a priori expectation of entailment 
relationships between them.

Of course, some applications would regularly take the merge of all GRDDL 
results - but other applications would not need to.

However, if any true document has two GRDDL results that contradict each 
other, then there would be a problem.

> However, can you shed some light on *why* the GRDDL result is not entailed 
 > by the original RDF?  Could entailment be used instead of GRDDL 
processing?
> 

It's not entailed because its too complicated. GRDDL allows an arbitrary 
transform to be used. Entailment often goes from complicated expressions 
to simpler ones.

One could get all the entailments to happen by using what is known as a 
semantic extension to RDF (see RDF Semantics).

However, this would be deeply problematic.

The way  a semantic extension works is that some text in English and 
mathematics is written, and a spec normatively declares that some RDF 
vocabulary has that meaning.

However, this process has many potential problems, in that it is easy to 
write English descriptions of the formal meaning of things, that while 
apparently sensible, is in fact nonsense - in the formal technical sense 
of not having a clear and coherent mathematical meaning.

Thus, when writing semantic extensions, I suggest the following guidelines:
- caution
- review

I have little doubt that one could attempt to write such a semantic 
extension; I do not expect that it would be possible to provide 
meaningful review.

Jeremy

Received on Friday, 25 January 2008 18:24:09 UTC