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

This topic's been quiet for a while, but for me, resolving this is pretty much my top priority. At this point, I think there are two basic solutions:

1) Use a separate _collection property_, which has some semantic relationship to the base property, where the range is specifically a collection.  For example:

      </gregg> a foaf:Person; :knowsCollection </gregg/knowsCollection> .
      :knowsCollection :collectionPropertyFor foaf:knows .

  Then the collection can reference each member and re-assert the relationship

      </gregg/knowsCollection> a hydra:Collection;
        hydra:member </markus> .
      </gregg> foaf:knows </markus> .

2) In a separate email, @lanthaler described an alternate using an intermediate object, such as the following:

      </gregg> a foaf:Person;
        :hasRelationshipIndirector [foaf:knows </gregg/knowsCollection>] .

  This could then reference the same type of collection I described above. It sort of breaks foaf:knows, except it does so on a blank resource, which could have some _catch-all_ semantic description, and it at least does not mess up the definition of the primary Person resource.

I see many advantages to the 2nd proposal, but would really like to see this more actively discussed.

Gregg Kellogg
gregg@greggkellogg.net

P.S. This is a duplicate of the issue response at <https://github.com/HydraCG/Specifications/issues/41#issuecomment-42867659>

On Mar 24, 2014, at 1:41 PM, Gregg Kellogg <gregg@greggkellogg.net> wrote:

> On Mar 24, 2014, at 8:14 AM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:
> 
>> Changing the subject line
>> 
>> On Friday, March 21, 2014 5:45 PM, Gregg Kellogg wrote:
>>> On Mar 21, 2014, at 7:52 AM, Markus Lanthaler wrote:
>>>> On Wednesday, March 19, 2014 10:44 PM, Gregg Kellogg wrote:
>>>>> </GreggKellogg> a foaf:Person;
>>>>> foaf:knows
>>>>>  [a foaf:Person; is hydra:member of </GreggKellogg/colleagues>],
>>>>>  </MarkusLanthaler> .
>>>>> 
>>>>> <MarkusLanthaler> a foaf:Person .
>>>> 
>>>> Hmm... I think this is a bit too clever and still creates a triple
>>>> that you don't want.
>>> 
>>> The notation is clever, just because Turtle doesn't allow me to express
>>> this. The notation in JSON-LD is straightforward IMO.
>> 
>> I think I disagree. You point to a blank node which is only there to be
>> referenced by the collection (in contrast to point to the collection) that
>> you are actually looking for. That's a bit too much magic IMHO.
>> 
>> 
>>> The concept of indirecting through another resource is basically a
>>> property path; it may be sophisticated, but it avoids asserting
>>> unnecessary triples (at least with IRI subjects). It does create
>>> additional BNode-subject triples, but in the context of Linked Data,
>>> these can be seen as necessary "semantic glue", and are easily
>>> filtered.
>> 
>> Well, everything is "easily filtered".. it doesn't really matter whether
>> it's a blank node or not I'd say.
>> 
>> 
>> [...]
>> 
>>>> While I don't really like the specific blank node solution you are
>>>> proposing, I find the principle quite interesting. We could avoid the
>>>> blank node, and thus a triple we don't want, entirely but just
>>>> including a member of collection directly:
>>>> 
>>>>  {
>>>>    "@context": {
>>>>      "foaf": "http://xmlns.com/foaf/0.1/",
>>>>      "hydra": "http://www.w3.org/ns/hydra/core",
>>>>      "memberOf": { "@reverse": "hydra:member" }
>>>>    },
>>>>    "@id" "GreggKellogg",
>>>>    "foaf:knows": {
>>>>      "@id": "MarkusLanthaler,
>>>>      "memberOf": "GreggKellogg/colleagues"
>>>>    }
>>>>  }
>>>> 
>>>> WDYT?
>>> 
>>> This would work fine, except for empty collections.
>> 
>> Good point!
>> 
>> 
>>> I would settle on
>>> this as a compromise if the BNode-based relationship I suggested is not
>>> palatable. Personally, I think the use of a BNode is a better call to
>>> dereference the memberOf relation to get values, whereas filling in on
>>> value might not make it clear that it is just a single representative
>>> member of such a collection.
>> 
>> I don't have a problem with the blank node per se but find the use of a
>> reverse property quite confusing in this instance. Maybe we should consider
>> creating a more explicit description of the collection instead. Something
>> along the lines of
>> 
>>   "@id" "/GreggKellogg/colleagues",
>>   "managing": {
>>     "subject": "/GreggKellogg/",
>>     "property": "foaf:knows"
>>   },
>>   "member": [
>>     { "@id": "/MarkusLanthaler" }
>>   ]
>> 
>> We could then even define a simple inference rule such as ?member =>
>> ?subject ?property ?member
>> 
>> 
>>> Considered as a SPARQL query, the use of a BNode indirection is
>>> something like the following:
>>> 
>>> SELECT ?member ?p ?o
>>> WHERE {
>>> </GreggKellogg> a foaf:Person .
>>> ?container hydra:member ?member .
>>> ?member ?p ?o .
>>> }
>>> 
>>> Which has a certain appeal to me.
>> 
>> I'm not sure what you want to illustrate with this SPARQL query.. copy and
>> paste error?
>> 
>> 
>>> I'd like to hear other people's thoughts on the merits of a direct
>>> collection relationship vs. an indirect relationship, and the problem
>>> that asserting a Collection as the value of a property who's range is
>>> something else presents.
>> 
>> Me too. I'll send a separate mail to public-lod and public-vocabs (of course
>> cc'ing this group) to get more opinions.
> 
> Perhaps if we could describe another kind of operation, where we could also provide a relative URL against which to perform the action. In the Hydra vocabulary, we could have something like the following:
> 
> </GreggKellogg> a foaf:Person
>  hydra:supportedOperation [
>    a GetRelatedCollectionOperation;
>    hydra:title "Get known relations";
>    hydra:description "Retrieves a collection of foaf:Person related to the subject through foaf:knows";
>    hydra:property foaf:knows;
>    hydra:uri </GreggKellogg/knows>;
>    hydra:method "GET";
>    hydra:returns foaf:Person
>  ] .
> 
> This increases the footprint of each class, but separates the operation of retrieving a collection, from the value of the property itself (which is asserted within the collection). Alternatively, the GetRelatedCollectionOperation could be specified within the supportedClass/supportedProperty/supportedOperation path within the vocabulary, where some form of URI template would be used to construct something relative the a specific entity's URL (in which case favoring </GreggKellogg/> would automatically allow <knows> as a relative path would work.).
> 
> foaf:Person a hydra:Class;
>  hydra:supportedProperty [
>    a hydra:SupportedProperty;
>    hydra:property foaf:knows;
>    hydra:supportedOperation  [
>      a GetRelatedCollectionOperation;
>      hydra:title "Get known relations";
>      hydra:description "Retrieves a collection of foaf:Person related to the subject through foaf:knows";
>      hydra:uri <knows/>;
>      hydra:method "GET";
>      hydra:returns foaf:Person
>    ]
>  ] .
> 
> Gregg
> 
>> --
>> Markus Lanthaler
>> @markuslanthaler
>> 
>

Received on Monday, 12 May 2014 18:15:44 UTC