Re: Questions about new collection design

Hi,

I know I am late with my concerns about the collection design, so I want
to thank everybody here that you are discussing this, although the
design is finalized already.

Am 05.02.2015 um 22:13 schrieb Markus Lanthaler:
> On 5 Feb 2015 at 10:22, Dietrich Schulten wrote:

>> I feel that using this design in services without RDF
>> backend will seriously prevent adoption.
> 
> Can you explain why? I know its adds some complexity but if you don't care
> about RDF anyway, what's the problem?
>

I do care about RDF, only I do not have a triple store as my backend. My
expectation is that clients need not use a reasoner either. I assume
that clients sometimes must resolve the json-ld against the @context to
identify the attributes uniquely, but they do not necessarily require an
RDF model or triple store for that. I recognize that RDF is the basis
for all this and I expect interesting use cases if the world of Linked
Data and the world of services come together.

> 
>> IMO it *must* be possible to say
>>
>> "foaf:knows" : { "@id": "/alice/friends" }
> 
> By definition it is not. There's nothing we can do about that. You would
> need to change FOAF to allow that. Other vocabularies don't suffer from this
> problem - Schema.org being the most popular. Since it doesn't use rdfs:range
> you can make such statements and don't need to use the indirection via
> hydra:collection.

Is it not possible to say

{
"@id" : "/alice"
"foaf:knows" : { "@id": "/alice/friends" }
}

if the target resource returned from /alice/friends is a json-ld set of
foaf:Person, as shown below?

[
  {"@id":"/bob",
   "@type": "http://xmlns.com/foaf/0.1/Person",
   "http://xmlns.com/foaf/0.1/name": "Robert Rumbaugh"
  },
  {"@id":"/zelda",
   "@type": "http://xmlns.com/foaf/0.1/Person",
   "http://xmlns.com/foaf/0.1/name": "Zelda Zackney"
  }
]

So far I thought the problem were that we return a hydra:Collection as
value of foaf:knows, effectively making a :Collection a foaf:Person by
inference.

But here we return individuals who are really foaf:Person.

Not legitimate?

> 
> 
>> We stray too far from plain json-ld and also from the simple way other
>> hypermedia types point to collections.
> 
> Because other hypermedia types assume much smarter clients (humans) than we
> do.
> 
> 
>> I have several other reasons, but I'll stop here.
> 
> I would be very interested in hearing them. So please share them if you find
> some time.

Other reasons are:
- since we do not use :knows as the single point to look up the people
Alice knows, but we introduce the collection as an alternative, clients
must check both :knows and the manages block to be sure Alice knows nobody

- it is easy to look up an attribute in a Json object. It is not so easy
to iterate over all collections and traverse each manages block to check
for :knows and then find the associated members.

- virtually "everything" becomes a :collection property. Many schema.org
classes use properties which may or may not be a collection. Look at
schema:Event: at least attendee, offers, organizer, performer, subEvent,
workPerformed are potential collections.
Instead of a Json object with distinct attributes for all of these, we
would have an event with no attributes but an @id and one huge
hydra:collection attribute having multiple nested manages blocks.

To ease adoption, things must be easy to use and understand. Therefore I
fear that this will prevent adoption by json users, who usually make it
a point to keep their json short, readable and easy to use. My
understanding was that a major purpose of json-ld was to inject
semantics into an otherwise terse and elegant json.

Part of my argument of course hinges on the assumption that json-ld
allows to link from one resource to another resource, also if the other
resource is a collection - as shown above.

Best regards,
Dietrich

Received on Friday, 6 February 2015 19:35:50 UTC