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/
