Re: status report - formal layer

Good, this feels as if we're making progress (or rather, you're making 
progress in a promising direction :-)).

I'll do some more playing around on Monday morning and see if I come up 
against anything we're missing.

Have a good weekend and thank you.

Phil.

Jeremy Carroll wrote:
> 
> Phil Archer wrote:
>>
>>
>> Jeremy Carroll wrote:
>> [snip]
>>>
>>> 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).
>>
>> I take this point. It may be that we can do something about it though. 
>> We have so far taken the view that a DR should be self-contained and 
>> that a package is therefore a group of self-contained units. Doing 
>> this means that the validity information (and attribution) is NOT 
>> inherited by DRs in the package. However... we then had to introduce 
>> the idea of using dcterms:isPartOf to force the processing of these 
>> "discrete DRs" in a particular order [1]. In such a scenario, yes, 
>> each DR would have its own validity and attribution.
>>
>> But it doesn't have to be this way...
>>
>> It would be possible I think to work with the package carrying the 
>> validity information that was then inherited by the DRs within that 
>> package - which I think from what you say would make life easier?
>>
>>
> 
> 
> Yes - I was thinking along these lines.
> 
> I was discussing this with Stuart - a possible view is then:
> 
> The unit of a POWDER description is a document, which may contain a 
> single wdr:DR or a single wdr:Package.
> 
> Either way the document has information pertinent to the relevance of 
> the document:
> e.g. validity and who vouches for it.
> 
> Operationally the process of trust is as follows:
> 
> for each possible document that you might be considering, you read that 
> document, then understanding what that document says about itself, if 
> you are satisfied that you want to act on that document (e.g. it is 
> valid, and is vouched for by an appropriate authority), then you load it 
> into your knowledge base (formally corresponding to an RDF merge using 
> the POWDER-S GRDDL result)
> 
> The resulting RDF graph consists of only valid POWDER DRs, which have 
> been vouched for by appropriate authorities.
> 
>  From the formal side the motivations for doing this way are:
> - it is known that temporal logics (i.e. dealing with time in a logical 
> way) is a hard problem
> - it is known that dealing with trust in logic is a hard problem
> - it is clear that POWDER deals with both time and trust, but in simple 
> ways
> - hence it feels inappropriate to do the time and trust parts in the 
> formal logical layer, but to deal with them in a pragmatic layer prior 
> to, but informed by, the logical treatment
> 
> It is a limitation of the current RDF technology that it is hard to talk 
> about part of an RDF graph, and its validity, or who vouches for that 
> part - hence the desire to talk about documents containing RDF/XML that 
> expresses those parts of the graph.
> I think it is possible to design documents of the 'right' size so that:
> 
> - validity and vouching are pertinent on a document by document level 
> (and not on a finer grain)
> - documents are large enough that the small scale powder user need only 
> write one document for their site, or maybe two.
> 
> - that the expectations on large publishers who may need to make 
> declarations that fit into complex workflows are intelligible and not 
> too burdensome.
> 
> Jeremy
>

Received on Friday, 18 January 2008 17:16:36 UTC