- From: Gregg Kellogg <gregg@greggkellogg.net>
- Date: Thu, 15 May 2014 16:11:53 -0700
- To: Markus Lanthaler <markus.lanthaler@gmx.net>
- Cc: public-hydra@w3.org
Gregg Kellogg
gregg@greggkellogg.net
On May 15, 2014, at 12:53 PM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:
> On Wednesday, May 14, 2014 9:46 PM, Gregg Kellogg wrote:
>> On May 14, 2014, at 12:17 PM, "Markus Lanthaler" wrote:
>>> 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?
>>
>> I think we can live with the vagueness, and keep the spirit of sameAs if we use an API
>> constraint with a property-path to describe the semantics of a specific relationship. For
>> instance, foaf:know is an indirect property described through sameAs/manages/property
>> such that it's value is restricted to foaf:knows. There are certainly other ways to do this, but
>> from an API perspective, it's not the semantics of sameAs that matter, but the path that goes
>> through it to a specifically identified Collection.
>
> I'm not sure I really understand what you are trying to say in this
> paragraph. Especially the sameAs bit confuses me. Are you saying that we
> declare the property-path pointing to the relevant collection to be the
> "same as" (i.e., not owl:sameAs) the foaf:knows property? That would
> probably be much more straightforward with the other approach I put forward
> a while ago:
>
>> {
>> "@id": "/markus",
>> "hasRelationshipIndirector": {
>> "schema:knows": "/markus/friends"
>> }
>> }
>
> That way we would really just need a property path. It's tricky to do that
> with the current proposal (seeAlso + manages)
>
> We could, however, simplify the approach to just mark a property as being
> "indirect(ly managed)".. so a simple flag would suffice. That would tell a
> client it either needs to look for the right collection in seeAlso (or
> whatever we decide to use) .
No, I wasn't saying that there is a property which is "sameAs" foaf:knows; I wrote sameAs, but meant seeAlso. What I was trying to say was that the fact that rdfs:seeAlso has vague semantics is not necessarily a barrier for Hydra. This can be managed in a Constraint in which rdfs:seeAlso is a property-path component. We might use the Hydra API to say that foaf:knows is an indirect property of foaf:Person, and there is a constraint to identify this by finding a collection which manages the property foaf:knows through a path such as rdfs:seeAlso/hydra:manages/hydra:property where the property value is constrained to be exectly foaf:knows. Of course, there may be other ways to do this.
Gregg
>>> 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?
>>
>> As a client, I need to know where to find foaf:knows relationships for a given class, and
>> that the class supports foaf:knows through some indirection. Given a collection managing
>> foaf:knows, I need to interact with it to add or remove members that manifest such a
>> relationship.
>
> So something like a constraint such as
>
> property: foaf:knows
> managedByCollection: true
>
> would do it I guess, right? Obviously we would need to explicitly define how
> the collection managing that property can be found.
>
> I think we are getting closer...
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>
>
>
Received on Thursday, 15 May 2014 23:12:23 UTC