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

Re: How to avoid that collections "break" relationships

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Tue, 25 Mar 2014 10:58:38 -0700
Message-ID: <5331C3CE.6020605@gmail.com>
To: Markus Lanthaler <markus.lanthaler@gmx.net>, public-hydra@w3.org, public-lod@w3.org, 'W3C Web Schemas Task Force' <public-vocabs@w3.org>

On 03/25/2014 10:40 AM, Markus Lanthaler wrote:
> On Tuesday, March 25, 2014 5:49 PM, Peter F. Patel-Schneider wrote:
>> Let's see if I have this right.
>>
>> You are encountering a situation where thenumber of people Markus knows
>> is too big (somehow).  The proposed solution is to move this information
>> to a separate location. I don't see how this helps in reducing the size
>> of the information, which was the initial problem.
> Cynical as usual :-) Let's just assume that the vast majority of the clients aren't interested in Markus' friends but just in information about him. Thus, they shouldn't have to process megabytes of friend relationships that they are to be ignoring anyway. Those few clients that are interested in those relationships, however, need a mechanism to find them.

Aah.  However, this is a new requirement.

So what you want is to be able to cherry-pick the data associated with Markus, 
and not even have to pay for transmitting the unwanted bits.  This is 
definitely not supported by schema.org.  To do this in general would require 
specifying the data that you want in the request.

>> Splitting this information into pieces might help. schema.org, along
>> with just about every other RDF syntax, doesnot require that all the
>> information about aparticularentity is in the same spot. The problem
>> then is to ensure that all the information is accessed together.
>>
>> schema.org, somewhat separate from other RDF syntaxes, does have
>> facilities for this.  All you needto do is to set up multiple pages,
>> for example .../markus1 through.../markusn
>> and on each of these pages include schema.org markup withcontent like
>> <.../markusi> schema:url <.../markus>
> I'm still wondering what schema:url is actually for and how it relates to Microdata's itemid, RDFa's resource and JSON-LD's @id... but that's a separate discussion.

Yeah.  I'm still waiting for the better documentation that was supposed to be 
coming shortly after ISWC 2013.
>
>
>> <.../markus> schema:knows <.../friendi1>
>> ...
>> <.../markus> schema:knows <.../friendimi>
>> Then on .../markus you have
>> <.../markus> schema:url <.../markus1>
>> ...
>> <.../markus> schema:url <.../markusn>
>> (Maybe schema:sameAs is a better relationshipto use here, but they both
>> should work.)
> Yeah, this would of course work, but it doesn't tell the client at all why it should follow schema:url links to /markus{n}. The same is more or less true abut schema:sameAs.
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>
>
>> Voila! (With the big provisio that I have no idea whether the schema.org
>> processors actually dothe right thing here, asthere is no indication of
>> what they do do.)
>>
>> peter
>>
>> PS:  LDP??
> Linked Data Platform: http://www.w3.org/TR/ldp/
>
>   
Received on Tuesday, 25 March 2014 17:59:07 UTC

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