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

On May 27, 2014, at 11:49 PM, "Markus Lanthaler" <markus.lanthaler@gmx.net> wrote:
> 
>> On Tuesday, May 27, 2014 12:02 AM, Gregg Kellogg wrote:
>>> On May 26, 2014, at 10:41 PM, "Markus Lanthaler" wrote:
>>> The design I like most is the one that one I summarized as "Link to the
>>> collection via a generic property". Specifically this one:
>>> 
>>>   </alice> hydra:hasCollection <alice/friends> .
>>> 
>>>   </alice/friends/> hydra:manages [
>>>     [hydra|rdf]:property schema:knows ;
>>>     [hydra|rdf]:subject </alice> .
>>>   ] .
>> 
>> Don't thing rdf:subject works, as it's domain is rdf:Statement, and I
> don't think we want to
>> invoke Reification, so best stick with hydra:property/subject.
> 
> Good point. Shall we introduce a class that represents the range of
> hydra:manages or is that not necessary in your opinion?

That makes sense, and can be used as the (a) domain for hydra:subject/property/object.

>> I also need hydra:object for some of the the reverse use-cases.
> 
> Yep. I just tried to keep the examples simple. If we choose this approach, I
> would strongly favor to also introduce hydra:object.
> 
> 
>> I presume the domain of hydra:manages is hydra:Collection.
> 
> Yeah (even though perhaps it actually make more sense to switch to something
> like schema:domainIncludes for Hydra than using RDF's domain. In any case,
> I've already updated the wiki to clarify what is meant.

schema:domainIncludes has fuzzy semantics. For hydra, better stick with rdfs, where possible, and owl, where necessary (such as hydra:property).

Do you think it's necessary to further describe supported collections using constraints? Perhaps this isn't necessary any more.

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

Received on Wednesday, 28 May 2014 14:55:58 UTC