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

On May 14, 2014, at 12:17 PM, "Markus Lanthaler" <markus.lanthaler@gmx.net> wrote:
> 
>> 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?

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.

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

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.

Gregg

> --
> Markus Lanthaler
> @markuslanthaler
> 
>

Received on Wednesday, 14 May 2014 19:46:10 UTC