- From: Pat Hayes <phayes@ihmc.us>
- Date: Tue, 25 Mar 2014 23:26:16 -0500
- To: Markus Lanthaler <markus.lanthaler@gmx.net>
- Cc: public-hydra@w3.org, public-lod@w3.org, W3C Web Schemas Task Force <public-vocabs@w3.org>
On Mar 25, 2014, at 11:29 AM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote: > 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. Hmm. I would be inclined to violate IRI opacity at this point and have a convention that says that any schema.org property schema:ppp can have a sister property called schema:pppList, for any character string ppp. So you ought to check schema:knowsList when you are asked to look for schema:knows. Then although there isn't a link in the conventional sense, there is a computable route from schema:knows to schema:knowsList, which as far as I am concerned amounts to a link. > 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. Well, there is going to have to be some pain somewhere. I get the impression that you want all of these to be true at once: 1. schema:knows applies to both individuals and to documents listing individuals, and works for both of them. 2. schema:knows is declared to only have individuals in its range. 3. RDFS and OWL reasoning will work on schema:knows. And sorry, this is impossible. You can decide to use a hack to keep 1. and ignore the semantics, or you can preserve the semantics and break 1. (my suggestion) , or you can keep both 1 and 2 but decide that RDFS and OWL are just irrelevant. I presume that 2. is already done for you by schema.org, but removing that would be a way to keep 1 and still use RDFS/OWL, albeit now somewhat weakened. But no matter how much you twist and turn, you can't have all three. > >> 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? Yes. Or restated in some more palatable form, if you like :-) Pat > > > -- > 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 ------------------------------------------------------------ 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 Wednesday, 26 March 2014 04:26:59 UTC