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

On Wednesday, May 14, 2014 12:49 AM Gregg Kellogg wrote:
> On May 13, 2014, at 11:22 AM, Markus Lanthaler wrote:
> >>>   </gregg/knowsCollection> :manages [
> >>>      :subject  </gregg/> ;
> >>>      :property foaf:knows
> >>>   ] .
> >> In your example, the seeAlso would presumably directly reference the
> >> collection, but would need to extract some useful properties of that
> >> collection, perhaps like this:
> >>
> >> </gregg> a foaf:Person;
> >>  rdfs:seeAlso </gregg/friends> .
> >> </gregg/friends> a hydra:Collection;
> >>  :manages [
> >>    :property foaf:knows;
> >>    :subject </gregg>
> >>  ] .
> >
> > That's indeed what I had in mind.
> 
> So as not to bring in semantics from VOID, and potentially further
complicate Hydra, I
> think your :manages proposal is probably the most effective. 

The only thing I'm not entirely happy about yet is the usage of rdfs:seeAlso
as I find it too vague. Granted, the definition of rdfs:seeAlso fits quite
well (see below) but the way it is used in practice doesn't really reflect
this IMO.

   "rdfs:seeAlso is an instance of rdf:Property that is used to indicate a
resource
    that might provide additional information about the subject resource.

    A triple of the form S rdfs:seeAlso O states that the resource O may
provide
    additional information about S. It may be possible to retrieve
representations
    of O from the Web, but this is not required. When such representations
may
    be retrieved, no constraints are placed on the format of those
representations.

    The rdfs:domain of rdfs:seeAlso is rdfs:Resource. The rdfs:range of
rdfs:seeAlso
    is rdfs:Resource.

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?


> Now, how to describe that in
> Hydra, so that a client looking for foaf:knows relationships will follow
the sameAs links, or
> do you think that's baked in so that _all_ Collection indirections are
down through
> rdf:seeAlso? Is there still a notion that foaf:knows, in some sense, is a
SupportedProperty,
> or perhaps an IndirectSupportedProperty? Maybe the Constraint/propertyPath
description
> handles this.

That's a very good point. I think it still is a SupportedProperty because in
the collection members you use that property. I think what we really need to
think about is whether we need to separate the enumeration of supported
properties of a class in general and the constraints that apply when a class
is used in "expects". The assumption I made in the beginning was that,
within a single Web API, a class is always used the same way when it appears
in "expects" (and that it only appears in one or very few operations'
"expects" property). I'm not so sure about that anymore.

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?


--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 14 May 2014 19:17:37 UTC