W3C home > Mailing lists > Public > public-vocabs@w3.org > March 2014

Re: How to avoid that collections "break" relationships

From: Pat Hayes <phayes@ihmc.us>
Date: Tue, 25 Mar 2014 23:26:16 -0500
Cc: public-hydra@w3.org, public-lod@w3.org, W3C Web Schemas Task Force <public-vocabs@w3.org>
Message-Id: <6C3733E8-F74E-4C6D-AB0E-7CC01B32CA9D@ihmc.us>
To: Markus Lanthaler <markus.lanthaler@gmx.net>

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:38 UTC