RE: How to avoid that collections "break" relationships (ISSUE-41) (was: hydra:Link)

On Wednesday, May 14, 2014 9:46 PM, Gregg Kellogg wrote:
> On May 14, 2014, at 12:17 PM, "Markus Lanthaler" wrote:
> > So I'm a bit on the fence. What are your thoughts on this? What about
> > something like a hydra:moreData or hydra:moreInformation property which
> > would be a sub-property of rdfs:seeAlso. Shall we require its values to
be
> > dereferenceable, i.e., set its range to hydra:Resource and thus make it
a
> > hydra:Link?
> 
> I think we can live with the vagueness, and keep the spirit of sameAs if
we use an API
> constraint with a property-path to describe the semantics of a specific
relationship. For
> instance, foaf:know is an indirect property described through
sameAs/manages/property
> such that it's value is restricted to foaf:knows. There are certainly
other ways to do this, but
> from an API perspective, it's not the semantics of sameAs that matter, but
the path that goes
> through it to a specifically identified Collection.

I'm not sure I really understand what you are trying to say in this
paragraph. Especially the sameAs bit confuses me. Are you saying that we
declare the property-path pointing to the relevant collection to be the
"same as" (i.e., not owl:sameAs) the foaf:knows property? That would
probably be much more straightforward with the other approach I put forward
a while ago:

>  {
>    "@id": "/markus",
>    "hasRelationshipIndirector": {
>      "schema:knows": "/markus/friends"
>    }
>  }

That way we would really just need a property path. It's tricky to do that
with the current proposal (seeAlso + manages)

We could, however, simplify the approach to just mark a property as being
"indirect(ly managed)".. so a simple flag would suffice. That would tell a
client it either needs to look for the right collection in seeAlso (or
whatever we decide to use) .


> > Regarding your second question: yes, I do think that the Constraints
design
> > we talked about previously helps in this regard but just if it is for
> > sending data. I haven't really thought about the reading/finding data
case
> > enough yet. Do we really need to express this upfront? Can we expect the
> > client to find it itself? Or does this introduce too much complexity on
the
> > client side? I have to thinker about that a bit more. What are your
> > thoughts?
> 
> As a client, I need to know where to find foaf:knows relationships for a
given class, and
> that the class supports foaf:knows through some indirection. Given a
collection managing
> foaf:knows, I need to interact with it to add or remove members that
manifest such a
> relationship.

So something like a constraint such as

    property: foaf:knows
    managedByCollection: true

would do it I guess, right? Obviously we would need to explicitly define how
the collection managing that property can be found.

I think we are getting closer...


--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 15 May 2014 19:54:12 UTC