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

On another use case for collections, and the relationship to the referencing entity, I commonly use the same Collection subclass to manage members from either direction. For example, I might use a sub-class of Collection ArticleCollection, whose members are Articles referenced from something. I use the same ArticleCollection from the Article entity using a reverse property, to collect all of the things that the Article might be about (e.g., SFGiants and Buster Posey).

If we use the :manages entity, as suggested, rather than using :subject, to identify the common subject of all members, I would use :object, to represent the common object of all members.  The two collections might look like the following:

</giants/articles> a :ArticleCollection;
  :manages [:subject </giants>; :property :article];
  :member </articles/1>, </articles/2>, </articals/3>, ...
</giants> :article </articles/1> .
</giants> :article </articles/2> .
...

From the other side, it might look like this:

</articles/1/abouts> a ArticleCollection;
  :manages [:object </articles/1>; property :article];
  :member </giants>, </BusterPosey>, ...
</giants> :article </articles/1> .
</BusterPosey> :article </articles/2> .

Gregg Kellogg
gregg@greggkellogg.net

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?
> 
> 
>> 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 Thursday, 15 May 2014 18:21:48 UTC