Re: Comments on the current data model

Hi Luc,

Thanks. I've a quick follow-up to four of the responses, interleaved below.

>  >(C) paragraph 6: "a partial order exists between events". I assume you
>  >mean a temporal order? What kind of ordering do you mean?
>
> ... partial ;-) .... between events...
> What is the issue?
>
> PM agree, statement seems clear to me.
> it's an order amongst events, not instants in time
> it's partial: you can't always say ev1 before ev2
>
> LUC: No change then
> ===================

OK, but if the only meaning of the order is that it is partial, then I
can assume that the order denotes how much I like those events, so E1
> E2 > E3 because I like E1 best. Surely it should have something to
do with time, causality, or similar?

>  >Sec 5.3.3.1:
>  >(C) I suggest that, as accounts are not introduced until later in the
>  >document, the generation-unicity constraint will not make sense here.
>  >Moreover, I think the constraint is more about accounts and what it
>  >means for them to be consistent than it is about generation events or
>  >process executions. Therefore, I suggest moving this constraint to the
>  >section on accounts.
>
> I am not sure I agree. I think it says a lot about generation, since
> provenance assertions are always in accounts (even if it is a default
> account of the provenance container).
>
> PM: the account is mentioned for accuracy of definition here. If you
> din't know about accounts, then this would just be correct without
> qualification.
> So I would leave it as is.
>
> Luc: OK
> ===================

I can't see what it would mean without knowledge of accounts, or how
it could be "correct without qualification". Surely it is simply not
true that only one PE can generate an entity independently of
accounts? Why do we not allow multiple granularities of description?

>  >(C) Under the definition given, you cannot have expressions in a
>  >container but not in an account. Does this imply that every Prov
>  >expression is made accessible as part of an account? I think this
>  >would be a good thing for clarity, but it is not explicit in the
>  >document (and also differs from OPM).
>
> Added sentence: Consequently, every provenance expression is always
> expressed in the context of an account, either explicitly in an
> asserted account, or implicitly in a container's default account.

Fine by me, though I note that the concept of "default account of a
container" will have to be clear for access and query purposes.

>  >Sec 5.5.4:
>  >(C) Second note: Wouldn't this mean that either account IDs or entity
>  >IDs can never be URIs, as a sequence of URIs would itself not be a
>  >URI? If so, that seems to make RDF serialisation difficult to achieve.
>
> TODO.
>
> Why do we need to have a URI for a qualified identifier?
>
> Why would this make serialization to RDF difficult. We are proposing for
> a qualified identifier to be only usable in wasComplementOf.

I mean that if the account has identifier ns1:accA, and the entity has
identifier ns2:entB, then what is the qualified identifier of the
entity? Even if, as said in the first note of Section 5.5.4, one of
the namespaces is the "default" namespace, then this does not seem to
resolve the problem.

Thanks,
Simon

-- 
Dr Simon Miles
Lecturer, Department of Informatics
Kings College London, WC2R 2LS, UK
+44 (0)20 7848 1166

Received on Monday, 10 October 2011 16:43:36 UTC