Re: status report - formal layer

Hi Jeremy,

Some comments, questions and other stuff below.

Jeremy Carroll wrote:
> 
> 
> I didn't make much progress on Friday over and above what I've already 
> pointed to.
> 
> http://www.w3.org/2007/OWL/wiki/POWDER
> 
> I need to do other work, and hope to work on the powder stuff again 
> either Thursday or Friday this week.

I've also been doing other things since and have just got back to this.
> 
> On the validity issue, my current thought is as follows.
> 
> - Each DR should be in its own document (at least notionally: i.e. there 
> is a URL that if you do a get you get the DR - that's not to exclude the 
> case where mutliple DRs are listed together in a single file, in 
> addition to the individual files).

Let me explore this a little. I might have an RDF/XML file that contains 
2 operational DRs:

<wdr:DR rdf:ID="DR_1" >
   ...
</wdr:DR>

<wdr:DR rdf:ID="DR_2" >
   ...
</wdr:DR>

So each of these has its own URI with a fragment identifier such as 
http://example.org/powder.rdf#DR_1 but you're saying this isn't going to 
be enough and that what we really need is http://example.org/DR_1 and 
for this to return a single RDF/XML instance that contains just 'DR_1'?

So practically I'd create my 2 DRs in the file as shown (so I can keep 
them all in one place) but I'd publish their identifiers in the form 
http://example.org/DR_1 and then do some server-side processing to 
extract the relevant DR from the repository and return it as a single 
RDF/XML instance?

I can see why this is important for the semantics (so that the metadata 
about the DR can be published in a block where rdf:about="") but we need 
to find a way to avoid server-side processing. How much can XSLT/GRDDL 
do for us here? Would it be able to do what's necessary? Requiring 
server-side processing would mean that it was really only labelling 
organisations that would deploy POWDER and it wouldn't be something Joe 
Lambda could easily add to his own website.

> - The validity refers to the validity of the file (and hence of the 
> individual DR).

OK

> - The subclass relationship corresponding to a DR  necessarily follows, 
> even if the DR is invalid (But invalid DRs may or may not be true).

This is because you can't say "I believe X" without asserting it?

> - To work out the formal meaning of a set of powder files, the first 
> step is to take the RDF merge of the valid files, and then take the RDF 
> semantics for that merge.
> 
> This follows the named graphs paradigm, in leaving 'difficult' stuff 
> (e.g. time) outside the formal treatment, but providing a pragmatic 
> treatment (ignore invalid files).

OK.

> 
> I still need to think through the relationship with packages.
> Unless the discussion indicates that the above approach is misguided, 
> I'll write it up, as part of the proposed formal treatment, and include 
> it in the wiki page.

See earlier question about packages - again, how far can XSLT/GRDDL take 
us? Can it process an operational Package and come up with a semantic 
package in which all URIsets are fully defined such that processing 
order is irrelevant?

Meanwhile I'm just having a go at editing the published draft of the DR 
doc [1] to see how it might look following this model.

I notice your suggestion of specifying a new grammar this isn't quite 
RDF/XML or XML and perhaps giving it a new MIME type. Last November we 
did consider an approach similar to what we're looking at now with an 
operational DR and a semantic one. The operational one would be written 
in XML, only the semantic one would be in RDF/OWL (this all came out of 
a conversation at TPAC with David Booth btw). When we looked at this as 
a group, the feeling was that we didn't want people to have to set 
different MIME types for two versions of a DR - because inevitably a lot 
of DR publishers would get it wrong - and that we'd be better sticking 
with one (or the other).

So for now I'd say let's stick to RDF/XML for the operational DR. Yes, 
it means keeping in some striping that we could perhaps do without but 
that's a small price to pay. Since we're working in RDF/XML (and not 
other serialisations of RDF) we might make greater use of 
parseType="resource" (the range of hasScope is defined as a resource Set 
(soon to be URI set we know)) so this might be enough to knock out a 
couple of lines we don't need?

Phil.

[1] http://www.w3.org/TR/2007/WD-powder-dr-20070925/

Received on Thursday, 17 January 2008 13:09:11 UTC