RE: How to avoid that collections "break" relationships

On Tuesday, March 25, 2014 7:25 PM, Niklas Lindström wrote:
> On Tue, Mar 25, 2014 at 6:58 PM, Markus Lanthaler wrote:
> > 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 wasn't talking about dereferencing URLs. What I meant was that
rdfs:seeAlso doesn't tell you anything by itself. You have to analyze
whether one of the things it points to is of interest to you. In most other
cases, the decision whether something is of interesting (or at least worth a
closer look) based on the property that is used to connect it to something
we are already interested in (e.g., the schema:knows relations of a person
we are interested in).


> > 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.

Definitely, yeah.


> 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.)

An alternative to "basic properties" such as rdf:seeAlso might be to
introduce something like hasRelationshipIndirection (obviously  with a
better name)

  {
    "@id": "/markus",
    "hasRelationshipIndirection": {
      "property": "schema:knows",
      "resource": "/markus/friends"
    }
  }

I haven't really thought this through yet but wanted to share it
nevertheless.


> (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".)

I agree, I also think it would it would be harder to understand.


--
Markus Lanthaler
@markuslanthaler

Received on Saturday, 29 March 2014 22:50:38 UTC