Re: How to avoid that collections "break" relationships

Hi Markus,


On Tue, Mar 25, 2014 at 6:58 PM, Markus Lanthaler
<markus.lanthaler@gmx.net>wrote:

> Hi Niklas,
>
> On Tuesday, March 25, 2014 5:21 PM, Niklas Lindström wrote:
> > On Tue, Mar 25, 2014 at 4:57 PM, Markus Lanthaler wrote:
> > > On Monday, March 24, 2014 5:54 PM, Michael Haschke wrote:
> > > > >> Would it be correct to summarize your question as, how do we
> enable
> > > > >> "mechanical" features like addressability and pagination to a
> value
> > > > >> collection in a way that doesn't interfere with its semantics
> (i.e.,
> > > > >> change the range)?
> > > > >
> > > > > Yup, this sums it up quite well. Thanks.
> > > >
> > > > I think we have the "pagination" feature already because we could
> > > > spread resource statements over various documents, e.g.
> > > >
> > > > on /markus/friends/page/1 describe
> > > >
> > > > </markus> schema:knows </alice>.
> > > >
> > > > and on /markus/friends/page/2 add
> > > >
> > > > </markus> schema:knows </zorro>.
> > >
> > > Yeah, but that's not the problem. The problem is how to link from
> > > /markus to /markus/friends[/page/{page}]
> > >
> > >
> > > > Maybe we would need a property in schema.org that let us relate
> > > > documents which contain statements about the resource, something very
> > > > similar to rdfs:seeAlso:
> > > >
> > > > </markus> a schema:Person ;
> > > >       rdfs:seeAlso </markus/friends/page/1> ;
> > > >       rdfs:seeAlso </markus/friends/page/2> .
> > >
> > > The mechanism also needs to tell in which relationship the resources
> > > stand to each other, in other words, by which property they are
> > > "connected" (schema:knows).
> >
> > I was thinking the same as Michael (using a mechanism akin to the
> > common use of rdfs:seeAlso), and then describe the nature of the page
> > linked to. Perhaps seeing it as a variant of a Linkset, to use VoID
> > terminology [1]. Giving us something like:
> >
> >     </markus> a schema:Person ;
> >         rdfs:seeAlso </markus/friends/page/1> .
> >         # or something like :describedBy (as an inverse of :about)
> >
> >     </markus/friends/page/1> a void:Linkset;    # or e.g. :LinkPage
> >         void:linkPredicate :knows .    #  ...
> >
> > (The difference to VoID is that this is reasonably occurring within
> > (the same dataset, just partitioned across various documents
> > (pages/records/named graphs/information resources/...).)
>
> OK.. this is quite similar to what we discussed in the Hydra CG (and what
> LDP does):
>
>     </markus> a schema:Person ;
>
>     </markus/friends/>:manages [
>        :subject </markus> ;
>        :property schema:knows
>     ] ;
>
> The thing I don't really like with these approaches is that you have to
> peek
> into the container to find out whether it contains/manages the information
> you are interested in.
>

It depends on what you mean by peek. Descriptions about them can - should -
be provided in the current document (here, in the data received from
</markus>). (More below.)


> I would like to have a relationship between, in this case, /markus and
> /markus/friends that makes it clear why I should process /markus/friends.
> Pat's proposal is the most elegant so far IMHO.
>

I think using such dedicated properties is harder to scale. You have to
create link properties for every "real" property you're looking for in
connection with the current subject of interest.

And the simple solution is to link to other documents describing the
subject (other than the one currently being read), using basic properties
(such as rdf:seeAlso, iana:describedby and similar). And *also*, and this
is the crucial part, to publish enough information within the *current
document*, about these other documents, to enable a client to decide what
to fetch next. That is, you should not require the client to fetch the docs
to understand that they are linksets. (Of course, if all else fails,
grabbing all related URLs should sort of work too. But a good information
publisher should make it easy to decide directly.)

(Note that this is basically what is already said in general about
providing useful information in linked data: to enable clients to discover
things of interest. (That is usually about nice labels for the things
linked, but it goes just as well for e.g. the language of documents, or in
this case, what kind of links are to be found.))

(Granted, you can say that it is just as easy to mint new "link properties"
and describe them everywhere, as it is to describe related pages. And that
the former can also bring lots of inference capabilities to the game.
However, I would argue that it would be harder to understand those
semantics, than to grok the notion of "pages with certain kinds of links
for current subject".)

Cheers,
Niklas



>
> --
> Markus Lanthaler
> @markuslanthaler
>
>
>