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

Gregg Kellogg
gregg@greggkellogg.net

On May 13, 2014, at 11:22 AM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:

> On Monday, May 12, 2014 11:31 PM, Gregg Kellogg wrote:
>> On May 12, 2014, at 1:15 PM, Markus Lanthaler wrote:
>>> On Monday, May 12, 2014 8:15 PM, Gregg Kellogg wrote:
>>>>     </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.
> 
> That's a very good point!
> 
> 
>>>> 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
>>  ] .
> 
> Niklas example was slightly different as the example above would mean that
> both /gregg and /gregg/friends are void:Datasets. Here's what Niklas wrote:
> 
> 
> On Tuesday, March 25, 2014 5:21 PM, Niklas Lindström wrote:
>> I was thinking the same as Michael (using a mechanism akin to the
>> common use of rdfs:seeAlso), and then describe the nature of the page
>> linked to. Perhaps seeing it as a variant of a Linkset, to use VoID
>> terminology [1]. Giving us something like:
>> 
>>    </markus> a schema:Person ;
>>        rdfs:seeAlso </markus/friends/page/1> .
>>        # or something like :describedBy (as an inverse of :about)
>> 
>>    </markus/friends/page/1> a void:Linkset;    # or e.g. :LinkPage
>>        void:linkPredicate :knows .    #  ...
>> 
>> (The difference to VoID is that this is reasonably occurring within
>> (the same dataset, just partitioned across various documents
>> (pages/records/named graphs/information resources/...).)

Fair point.

> Back to Gregg's mail...
> 
>> 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.
> 
> Nope, at least not in Niklas' example. The Collection is the Linkset (or
> LinkPage). So it's actually quite close to my :manages proposal above. We
> could of course flatten that by using :managedSubject, :managedProperty
> instead of :manages along with :subject and :property if people prefer that.
> 
> 
>>> 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>
>>  ] .
> 
> That's indeed what I had in mind.
> 
> 
>> 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.
> 
> See above. It's really more or less the same.
> 
> 
>>> 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.
> 
> Right, I just wanted to add it to have a more or less complete overview of
> all options we discussed so far.
> 
> 
>>> Gregg, at this stage, what would be your preferred approach?
> 
> So? :-)

So as not to bring in semantics from VOID, and potentially further complicate Hydra, I think your :manages proposal is probably the most effective. 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.

Gregg

> --
> Markus Lanthaler
> @markuslanthaler
> 
> 
> 
> 

Received on Tuesday, 13 May 2014 22:49:50 UTC