Re: collection access: inferred property vs. syntax

On Tue, Feb 01, 2005 at 11:19:57AM -0500, Eric Prud'hommeaux wrote:
> As DanC pointed out, any inferred triple can't be distinguished from a
> ground fact. The exciting difference with olw:member is that we turn a
> closed list into repeated properties. This has impact when we ask the
> members of a list and want to know that was a whole list.
> 
> Infered property owl:member approach:
> 
>   Server1 knows:
>     Joe hasAssets (house, car, boat).
> 
>   Client1 asks Server1:
>     CONSTRUCT *
>     WHERE { (Joe hasAssets ?list) (?list owl:member ?asset) }
> 
>   Client1 learns:
>     Joe hasAssets ?list. ?list owl:member house, car, boat.
> 
>   Client2 asks Client1 (same query):
>     SELECT ?asset
>     WHERE { (Joe hasAssets ?list) (?list owl:member ?asset) }
> 
>   Client2 learns:
>     house
>     car
>     boat.
> 
> We have closure but no confidence that we have the complete list.
> 
> Special syntax approach 1, constraint extension:
> 
>   Server1 knows:
>     Joe hasAssets (house, car, boat).
> 
>   Client1 asks Server1:
>     CONSTRUCT *
>     WHERE { (Joe hasAssets ?list) }
>       AND (?list MEMBER ?asset)
> 
>   Client1 learns, um, I dunno, maybe MEMBER makes CONSTRUCT * include
>   the ground facts:
>     Joe hasAssets (house, car, boat).
> 
>   Client2 asks Client1 (same query):
>     SELECT ?asset
>     WHERE { (Joe hasAssets ?list) }
>       AND (?list MEMBER ?asset)
> 
>   Client2 learns knows is has a complete list of:
>     house
>     car
>     boat.
> 
> Special syntax approach 2, triplePattern keyword:
>     CONSTRUCT *
>     WHERE { (Joe hasAssets ?list) (?list %MEMBER ?asset) }
> 
> The motivation for approach 2 is that scalar constraints can be
> processed without adding solutions to the set (I think). In addition,
> it may look more natural to have that %MEMBER arc in the graph rather
> than in the scalar constraints.
> 
> 
> Things get a bit more confusing when there are multiple lists:
> 
>     Eric sharesOfficeWith (Philippe, David),
>                           (Michiko, Yoshio, ...).
> 
>   Client1 asks Server1:
>     CONSTRUCT *
>     WHERE { (Eric sharesOfficeWith ?list) (?list owl:member ?who) }
> 
>   Client1 learns:
>     Joe hasAssets ?list. ?list owl:member (Philippe, David, Michiko, 
> 					   Yoshio, ...)

oops, screwed up. Those parens aren't there.

    Joe hasAssets ?list. ?list owl:member Philippe, David, Michiko, 
					  Yoshio, ...
Not using the shorhand ',' syntax:

    Joe hasAssets ?list.
    ?list owl:member Philippe.
    ?list owl:member David.
    ?list owl:member Michiko.
    ?list owl:member Yoshio.
    ...

> which is not wrong, but slightly misleading. The magic predicate rule
>   {?x sharesOfficeWith ?l.
>    ?l owl:member (?m1, ?m2). } => { ?m1 sitsNear ?m2 }

I should have just said { ?m1 sharesOfficeWith ?m2 }

> could be valid for the ground facts (if the binding made sure that no
> ?m1 and ?m2 came from different lists), but couldn't be made to work
> on what Client1 learned. 
> 
> 
> All in all, I'd like to walk away from this (or risk having to specify
> statments like "I dunno, maybe MEMBER makes CONSTRUCT * include the
> ground facts." I know we should be seeing what we *can* do with RDF
> rather than what we can't, but I can't help picking at things.
> -- 
> -eric
> 
> office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
>                         Shonan Fujisawa Campus, Keio University,
>                         5322 Endo, Fujisawa, Kanagawa 252-8520
>                         JAPAN
>         +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
> cell:   +81.90.6533.3882
> 
> (eric@w3.org)
> Feel free to forward this message to any list for any purpose other than
> email address distribution.



-- 
-eric

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
                        JAPAN
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +81.90.6533.3882

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.