- From: Gregg Kellogg <gregg@greggkellogg.net>
- Date: Mon, 24 Mar 2014 13:41:18 -0700
- To: Markus Lanthaler <markus.lanthaler@gmx.net>
- Cc: public-hydra@w3.org
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, 24 March 2014 20:41:49 UTC