Re: status report - formal layer

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 16:44:29 UTC