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

On May 12, 2014, at 1:15 PM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:

> On Monday, May 12, 2014 8:15 PM, Gregg Kellogg wrote:
>> 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 .
> 
> Interesting.. so you would set the link from knowsCollection to knows and
> not vice-versa? What about asserting it on a, what we currently call,
> SupportedProperty?

I was just illustrating such a possible assertion. In fact, I did create a hydra:collectionProperty to use on a SupportedProperty, but I didn't find this particularly transparent or satisfying. In fact, it's easier to consider foaf:knows to not be a supported property, in this case.

>>  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.
> 
> I would also like to hear more opinions on this. I think it has a number of
> advantages but, as Gregg points out, it is a bit weird from a semantical
> point of view.
> 
> There's also a third option which would be somewhat similar to what LDP
> does. Namely assert what subject-property pair the collection is managing.
> Something like
> 
>    </gregg/knowsCollection> :manages [
>       :subject  </gregg/> ;
>       :property foaf:knows
>    ] .

This is also quite close to something Nikas suggested from the VOID vocabulary [1]:

</gregg> a foaf:Person;
  rdfs:seeAlso [
    a void:Linkset;
    void:subjectsTarget </gregg>;
    void:objectsTarget </gregg/friends>;
    void:linkPredicate foaf:knows
  ] .

Although, this does not assert the relationship in the Collection, but in the Linkset. It does have the advantage of being a pattern from a widley-deployed vocabulary for describing datasets.

> The link to the collection can then be done by something very generic such
> as rdf:seeAlso.

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>
  ] .

They really both have the same amount of indirection, but in your case, it's more :subject => :collection => :manages, and in the VOID case, its :subject => :Linkset => :collection, which does seem a little more natural to me.

> Last but not least, for some vocabularies (most notably Schema.org) simply
> sticking to the current approach would work as well but introduces an
> undesired triple unless you remove it when you ingest the data
> 
>    </GreggKellog> schema:knows </gregg/knowsCollection>

Well, I've already objected to this pattern, so that would be a no-go for me.

> Gregg, at this stage, what would be your preferred approach?
> 
> 
> --
> Markus Lanthaler
> @markuslanthaler

Gregg

[1] http://lists.w3.org/Archives/Public/public-hydra/2014Mar/0125.html

Received on Monday, 12 May 2014 21:31:45 UTC