Re: mentionOf representation in RDF (was: prov-links ready for review)

Hi Graham,

I thought about this as well when I was reviewing PROV-Links, but ended up
liking the constraint. The way it is now, the constraint provides you with
some certainty about which aspects the specializing entity has, while it
doesn't limit expressiveness.

if you want to express that an entity has aspects inherited from two
bundles, you can say:

mentionOf(e, e1, b1)
mentionOf(e3, e2, b2)
specializationOf(e, e3)

In RDF this becomes
  e prov:mentionOf e1
  e prov:asInBundle b1
  e3 prov:mentionOf e2
  e3 prov:asInBundle b2
  e prov:specializationOf e3

essentially, one extra line, without ambiguity of which entity was
mentioned in which bundle.
(Or am I breaking any contraints here?)

- Tom

2013/4/9 Graham Klyne <graham.klyne@zoo.ox.ac.uk>

> Hi Luc,
>
> Just for the record, I'm OK with these changes.  I.e. no blockers.  But in
> the spirit of exploration, I'll pursue one of your responses a little
> further...
>
> On 08/04/2013 22:24, Luc Moreau wrote:
>
>>  > Section 5
>>  >
>>  > I'm not understanding the motivation or purpose of the constraint
>>  >
>>  >    IF mentionOf(e, e1, b1) and mentionOf(e, e2, b2), THEN e1=e2 and
>> b1=b2.
>>  >
>>  > e.g. It seems to me that if bundle b1 has specializationOf(e1, e2) or
>>  > mentionOf(e1, e2, b2) then it would make sense for e to be a
>> specialization of
>>  > distinct entities e1 and e2.
>>  >
>>  > Rather than just e1 = e2, is it not sufficient to allow:
>>  >
>>  >    specializationOf(e1,e2) OR specializationOf(e2,e1) OR e1 = e2
>>  >
>>  > ?
>>
>>
>> The reason for this constraint is the rdf encoding in two separate
>> properties.
>>
>> With a ternary relation, we could express
>>   mentionOf(e, e1, b1) and  mentionOf(e, e2, b2).
>>
>> In rdf, we would have
>>   e prov:mentionOf e1
>>   e prov:asInBundle b1
>>   e prov:mentionOf e2
>>   e prov:asInBundle b2
>>
>> which would allow us to express
>>   mentionOf(e, e1, b2) and  mentionOf(e, e2, b1)
>> but nothing requires e1 to be described in b2 and e2 in b1.
>>
>
> Ah, yes, I'd forgotten that aspect.  But I can't help wondering if this is
> a case of the tail wagging the dog: designing semantics to fit a particular
> syntactic pattern for a particular representation.
>
> An alternative RDF representation, arguably more in line with the
> published best-practice note for dealing with n-tuples (
> http://www.w3.org/TR/swbp-n-**aryRelations/#pattern1<http://www.w3.org/TR/swbp-n-aryRelations/#pattern1>),
> might be:
>
>   e prov:mentionOf
>     [ prov:specializationOf e1 ; prov:asInBundle b1 ] ,
>     [ prov:specializationOf e2 ; prov:asInBundle b2 ] .
>
> Or, equivalently:
>
>   e prov:mentionOf _:m1, _:m2 .
>   _:m1 prov:specializationOf e1 ; prov:asInBundle b1 .
>   _:m2 prov:specializationOf e2 ; prov:asInBundle b2 .
>
> Corresponding to
>
>   mentionOf(e, e1, b1)
>   mentionOf(e, e2, b2)
>
> where prov:mentionOf in the RDF might even be replaced with
> prov:specializationOf, and prov:asInBundle with prov:has_provenance.
>
> (In constructing this example, I didn't set out to re-open the other point
> I raised about the need for a new relation, but the introduction of the
> extra RDF node here provides a place to hang the additional aspect(s)
> associated with the two mentions.)
>
> #g
> --
>
>
>