Re: status report - formal layer

Phil Archer wrote:
> Jeremy,
> 
> Can I just ask a quick question about what you've written in the OWL wiki.
> 
> Your Example of POWDER Full is in two parts - one that is an "OWLed up" 
> version of the primary example DR and another which expresses the sub 
> class relationship. Is your view of POWDER Full (or of a DR-S) that it 
> is both of these or just one of them?
> 
> It looks to me as if an RDF/XML instance as shown below, which is the 
> sub class relationship plus the attributions triples, does the whole 
> thing? hence the point about each DR having to exist as a separate 
> document?
> 
> Phil.
> 
> <rdf:RDF>
> 
>  <rdf:Description rdf:about="">
>     <foaf:maker rdf:resource="http://authority.example.org/foaf.rdf#me" />
>     <dcterms:issued>2007-07-02</dcterms:issued>
>     <wdr:validFrom>2008-07-07</wdr:validFrom>
>     <wdr:validUntil>2008-07-07</wdr:validUntil>
>     <dc:description>Textual information to display to end users
>  </dc:description>
> 
>  <wdr:URISet rdf:nodeID="URIs">
>       <owl:intersectionOf rdf:parseType="Collection">
>         <owl:Restriction>
>           <owl:onProperty rdf:resource="&wdr;includeHosts" />
>           <owl:hasValue>example.org</owl:hasValue>
>         </owl:Restriction>
>       </owl:intersectionOf>
>  </wdr:URISet>
> 
>  <owl:Class rdf:nodeID="descriptors">
>       <owl:intersectionOf rdf:parseType="Collection">
>         <owl:Restriction>
>           <owl:onProperty rdf:resource="&ex;property1" />
>           <owl:hasValue>value 1</owl:hasValue>
>         </owl:Restriction>
>         <owl:Restriction>
>           <owl:onProperty rdf:resource="&ex;property2" />
>           <owl:hasValue>value 2</owl:hasValue>
>         </owl:Restriction>
>       </owl:intersectionOf>
>  </owl:Class>
> 
>  <owl:Restriction>
>    <owl:onProperty rdf:resource="&wdr;hasURI"/>
>    <owl:someValuesFrom rdf:nodeID="URIs"/>
>    <rdfs:subClassOf rdf:nodeID="descriptors"/>
>  </owl:Restriction>
> 
> </rdf:RDF>
> 

If we choose to make the GRDDL transform make the DR-S include the 
subClassOf relationship as above, then we have the issue that in a 
package (or any collection of DRs) some of the DRs may be valid and some 
may be invalid, and all the subClassOf relationships are in the same 
file, and it is unclear how to distinguish the ones we want to claim 
(the valid ones), from the ones we don't (the invalid ones).

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


If we are going down the line of including the subClassOf triple then it 
is certainly helpful to have each subClassOf triple in a different file 
from the other subClassOf triples, because we can then apply pragmatic 
methods for choosing which files to believe (the ones containing a valid 
DR), and which files not to believe (the ones containing invalid DRs).

We can of course do things differently; and your arguments seem to 
suggest that we should.

Here are two different ways:

A: don't include any subClassOf triples, but include that in the 
additional semantics we give to *valid* DRs.
I think I will migrate the Wiki stuff to this solution.
It makes the formal semantics more problematic in that a date is 
required ....

B: use XSLT 2.0 as our GRDDL processor, and go somewhat outside the 
scope of GRDDL rec to have multiple results from one transform and so do 
the named graphs approach but on the client side not the server side.
(It might be possible to do this within the current GRDDL spec., with a 
lot of ingenuity).

C: the named graph approach discussed above which, for some packages, 
requires too many files, and misses one of your requirements (hand 
editing possible)



 > 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?

That's fine.

Jeremy

Received on Thursday, 17 January 2008 18:15:32 UTC