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

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), 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
--

Received on Tuesday, 9 April 2013 09:32:14 UTC