RE: How to avoid that collections "break" relationships

On Tuesday, March 25, 2014 5:08 PM, Jason Douglas wrote:
> I find that so awkward since :knows is already a repeated property.
> Now we have denormalized semantics and queries have to look at both
> properties... and the only gain is the metadata about pagination.
> That's why I prefer an orthogonal mechanism like knows/collection
> for just the metadata.

Jason, how is knows/collection different from Pat's :knowsList approach below? AFAICT they are exactly the same:

  schema:knows/collection :listPropertyOf schema:knows .

  where :listPropertyOf has the semantic condition

  aaa listPropertyOf bbb
  xxx aaa ddd
  ddd schema:itemListElement yyy

  imply

  xxx bbb yyy

So

  </markus> schema:knows/collection </markus/friends> .
  </markus/friends> schema:itemList </pat>, </jason> .

implies

  </markus> schema:knows </pat>, </jason> .


Pat proposal makes the semantics explicit whereas you seem to suggest to infer the semantics based on the URL's structure, which is against the principle of URI Opacity [1].


[1] http://www.w3.org/TR/webarch/#uri-opacity


--
Markus Lanthaler
@markuslanthaler




------------ Original Message ------------
On Tue Mar 25 2014 at 9:01:33 AM, Pat Hayes <phayes@ihmc.us> wrote:
Seems to me that the, um, mistake that is made here is to use the same property schema:knows for both the individual case and the list case. Why not invent a new property for the list case, say :knowsList, and add a relationship between them as an RDF triple:

:knowsList :listPropertyOf schema:knows .

where :listPropertyOf has the semantic condition

aaa listPropertyOf bbb
xxx aaa ddd
ddd schema:itemLIstElement yyy

imply

xxx bbb yyy

Which can be published as a reference in the home document for the URL for :listPropertyOf , but implemented by whatever code anyone finds handy.

Pat Hayes

On Mar 24, 2014, at 10:24 AM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:

> Hi all,
>
> We have an interesting discussion in the Hydra W3C Community Group [1]
> regarding collections and would like to hear more opinions and ideas. I'm
> sure this is an issue a lot of Linked Data applications face in practice.
>
> Let's assume we want to build a Web API that exposes information about
> persons and their friends. Using schema.org, your data would look somewhat
> like this:
>
>  </markus> a schema:Person ;
>            schema:knows </alice> ;
>            ...
>            schema:knows </zorro> .
>
> All this information would be available in the document at /markus (please
> let's not talk about hash URLs etc. here, ok?). Depending on the number of
> friends, the document however may grow too large. Web APIs typically solve
> that by introducing an intermediary (paged) resource such as
> /markus/friends/. In Schema.org we have ItemList to do so:
>
>  </markus> a schema:Person ;
>            schema:knows </markus/friends/> .
>
>  </markus/friends/> a schema:ItemList ;
>            schema:itemListElement </alice> ;
>            ...
>            schema: itemListElement </zorro> .
>
> This works, but has two problems:
>  1) it breaks the /markus --[knows]--> /alice relationship
>  2) it says that /markus --[knows]--> /markus/friends
>
> While 1) can easily be fixed, 2) is much trickier--especially if we consider
> cases that don't use schema.org with its "weak semantics" but a vocabulary
> that uses rdfs:range, such as FOAF. In that case, the statement
>
>  </markus> foaf:knows </markus/friends/> .
>
> and the fact that
>
>  foaf:knows rdfs:range foaf:Person .
>
> would yield to the "wrong" inference that /markus/friends is a foaf:Person.
>
> How do you deal with such cases?
>
> How is schema.org intended to be used in cases like these? Is the above use
> of ItemList sensible or is this something that should better be avoided?
>
>
> Thanks,
> Markus
>
>
> P.S.: I'm aware of how LDP handles this issue, but, while I generally like
> the approach it takes, I don't like that fact that it imposes a specific
> interaction model.
>
>
> [1] http://bit.ly/HydraCG
>
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>
>
>
>
>

------------------------------------------------------------
IHMC                                     (850)434 8903 home
40 South Alcaniz St.            (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile (preferred)
phayes@ihmc.us       http://www.ihmc.us/users/phayes

Received on Tuesday, 25 March 2014 16:36:49 UTC