Re: PROV-ISSUE-145 (Tlebo): qualified identifiers may not work well with named graphs [Data Model]

On 14/11/2011 00:13, Stian Soiland-Reyes wrote:
> On Sun, Nov 13, 2011 at 11:50, Graham Klyne<GK@ninebynine.org>  wrote:
>
>> Generally, though, I think it is not a good idea to allow different accounts
>> to use the same URI for different entities.  While accounts may contain
>> statemenbts that are specific to the account, they should also provide for
>> inferences about things (specifically, Entities) that hold outside the
>> context of an account; e.g. entity1 derivedfrom entity2, if true, should be
>> true independently of any account considered.
>
> We can't really enforce different provenance asserters to not make
> conflicting provenance assertions in different accounts - the
> possibility of this is just a fact of life. We can advice against it,
> but not prevent it.

Of course you can't - that's the web all over.

But I don't think you should create a specification that says it's not a 
conflict to do so.

The problems arise when you combine these different "accounts" (according to RDF 
rules for graph merging).  In choosing to combine RDF graphs, you have to make a 
trust judgement that the various sources are using URIs in consistent ways.  If 
a URI is used in conflicting/contradictory ways in the sources, then the 
resulting graph may be unsatisfiable, or fail to describe the state of the world 
that it is intended to describe.

> Just like you can't tell if I am now writing a secret book explaining
> about how Graham Klyne found the green Easter Bunny in the loft, you
> can't know that someone else is not making a contradictory provenance
> assertion about the URI which resource you are asserting something
> about.
>
> In RDF, if you are worried about this, you can counteract this by
> minting your own fresh URIs (which can deliberately be contradicted
> once they are known) or bnodes (which are unique per document/account,
> can't as easily be crashed, but then again can't be referred to from
> other provenance accounts of your own making).
>
>
> An account is just that, it's one "view", "understanding" or "guess"
> of how which things happened. Two different accounts might have a
> different understanding of what exactly<http://example.com/me>  means
> - and therefore have a different kind of provenance trail. These
> accounts might or might not be reconsilable, and certainly doing so
> requires some isolation of the account assertions, using named graphs
> or other scoping, like the container() and account() structures in
> PROV-ASN.

If the account is to be represented in RDF, then it MUST follow RDF's semantics 
for interpreting URIs.  Without named graphs, that means the same URI denotes 
the same thing wherever it appears.  With named graphs... well, we don't really 
know yet, but I think it would be confusing or unhelpful to treat them as 
locally scoped variables.

It's not as if we have a shortage of available URIs :)

> A good hint of what kind of understanding the two accounts have of the
> entity is by looking at their attributes, but ultimately there are
> still no guarantees that they are truly talking about "the same
> thing", just like you can't truly be sure who I meant if I casually
> said something about "the prime minister".

In general, yes, but see above about trust judgement.

#g

Received on Monday, 14 November 2011 11:01:44 UTC