collection access: inferred property vs. syntax

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

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