RE: How to avoid that collections "break" relationships

On Tuesday, March 25, 2014 5:00 PM, Pat Hayes 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.

Exactly.. it is especially problematic if rdfs:range is involved.


> 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

Yeah, that's very similar to an idea I had (but it wasn't so elegant). The
issue is that you won't "discover" :knowsList if you look for schema:knows
unless you infer the "xxx bbb yyy" triples. In other words, if you don't
know :knowsList and thus ignore it, you would neither find the collection
nor the schema:knows relationships.

The alternative would be to reverse the property/list property relationship:

  schema:knows :listProperty :knowsList

But that has the disadvantage that the original property's definition needs
to be updated. So the list properties you make up yourself couldn't be found
by just following links from schema:knows. Thus, it is really schema.org in
this case which would have to basically double the number of properties.


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

You mean the "semantic condition" could "be published as a reference" at
:listPropertyOf?


--
Markus Lanthaler
@markuslanthaler



> 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:30:13 UTC