GRDDL and powder

Renaming this thread.
Note we are no longer talking about multiple results or named graphs, 
just two different designs for using GRDDL within POWDER.

Booth, David (HP Software - Boston) wrote:

> 1. It relies on a corner feature of RDF/XML, though perhaps it is only a corner feature to 
 > me.  Maybe to others it is a central feature.  :)

I think it is intended to allow the sort of usage I was envisaging of a 
specialist sub-dialect that can still use the extensibility of RDF/XML, 
while being in another namespace, which also as some control.


> So regarding POWDER, I would be quite uncomfortable with POWDER using this 
 > RDF/XML + GRDDL approach.  I also don't see any benefit to it over an 
XML +
 > GRDDL approach.
> To be clear, by an "XML + GRDDL" approach I mean: define POWDER in terms of 
 > abstract RDF, but also define a custom XML format whose semantics are 
*entirely*
 > defined by the RDF resulting from its GRDDL transformation.  This 
would give
 > the combined benefits of:
> 
>  - a concise XML serialization for those who want it, so XML tools can be used if desired;
> 
>  - clear semantics (given by GRDDL-generated RDF); and
> 
>  - compatibility with the Semantic Web, so standard RDF tools can also be used.
> 

My sense of the goals of the XML format for powder are:

a) the operational semantics should be fairly easy to implement over the 
XML format
b) the XML format should be fairly easy to write by hand (for moderately 
simple Web sites, obviously a complicated web site with a difficult 
description might be quite a lot of work to describe).
c) it should be fairly easy to add additional metadata in an open ended 
fashion - this metadata can be: about the powder document and its 
assertions etc. or about the resources described in that document

It is (c) that motivates my, mildish, preference for using a dialect of 
RDF/XML for POWDER.

My sense of the goals for the formal meaning of the powder document are:

A) the formal meaning should provide adequate motivation for the 
operations triggered in the operational semantics (e.g. if the 
operational semantics means that access to a resource with some specific 
URI should be blocked when parental controls are on, then the formal 
semantics should only have interpretations which interpret that 
particular URI as identifying a resource in a class of adult content)
B) be based on the semantic web with as little 'powder specials' as 
possible.

I am fairly clear that (B) is not zero - two areas where powder specials 
are definitely needed are to do with:
- referring to the parts of URIs (e.g. hosts)
   [Technically this might be possible with regex's and XML Schema 
datatypes derived  by pattern, and OWL 1.1 but
      - OWL 1.1 is still a way off
      - the regex's are disgusting, particular if you want to include 
URI normalization in the process, which the operational semantics do 
include]


It seems to me that (A)+(B) result in fairly complicated OWL documents 
to describe what a POWDER document is saying (judging from the 
operational semantics). Hence we need to have GRDDL to meet the ease of 
use goal (b).

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.

We are not expecting the majority of POWDER processors, or POWDER 
authors to understand this. At some level the GRDDL usage is as 
documentation of the formal meaning; it aslo permits POWDER documents to 
play a full role in other undefined semantic web applications involving 
merging of data from multiple sources, and because of design criterion 
(A) such applications don't just have the gist of the meaning, but have 
the meaning that the operational semantics actually implements.

I see the formal meaning part as the tail, and the XML format and its 
operational semantics as the dog, i.e. the typical POWDER application 
will either be an XML application or a light weight RDF application. It 
would not usually have an OWL reasoner available.

 > Regarding GRDDL, I think it was a mistake to include that feature in
 > the GRDDL spec.  I think it would have been better to say that the
 > GRDDL results of an RDF/XML document -- or any other RDF
 > serialization, for that matter -- are *only* the RDF graph represented
 > by that document.
 >

However, that decision was made.

I think in its defence, the case I have in mind, where we have a 
namespace other than the RDF namespace, but conform with RDF/XML syntax 
and serve as application/rdf+xml is one where we would expect that the 
namespace document may add stuff over and above the RDF/XML reading, and 
that given the monotonic nature of the semantic web, that the namespace 
might license further meaning that is not licensed simply by the RDF 
specs. This is an extensibility point (in both the RDF and the GRDDL 
specs), and it seems to me, to be a deliberate extensibility point, and 
hence legitimate to use it.

An illegitimate use would be to change the meaning so that the simple 
RDF meaning of document was false, since this would contradict the 
monotonic nature of the semantic web, and also undermine the faithful 
rendition principle of GRDDL where each GRDDL result, including that 
formed by the simple RDF/XML reading is vouched for.



Jeremy

Received on Thursday, 24 January 2008 10:09:17 UTC