Re: AS2.0: JSON and/or RDF based?

On 02/09/2015 05:11 AM, Erik Wilde wrote:
> hello elf.
> 
> On 2015-02-08 16:47, ☮ elf Pavlik ☮ wrote:
>> On 02/08/2015 05:10 PM, Harry Halpin wrote:
>>> I think the charter is clear: It's JSON-based. Any use of RDF(S) or
>>> OWL inference is fine or alternative serializations is fine, but
>>> should not be required (and thus non-normative).
>> Let's try to clarify if further! Do you say that we can use
>> rdfs:subClassOf but can not use it as formal way to say that one can
>> consider an individual in given sub class also an individual in its
>> super class?

Quick note - in real-world uses of RDF, most "reasoners" I've seen don't
deal with messy data and don't scale (from my experience at search in
Yahoo!).

So we can't enforce a *generic* RDF processing model with steps like "5.
Run your local RDF(S) reasoner and take all resulting triples" if we
want adoption outside of the world using RDF. Note that RDF is tricky
even for its fans - even your formal definition is incorrect insofar as
RDF(S) subClassOf does not even deal with individuals ala OWL, but with
classes :)

However, of course we can lean on 'subclass' since this a well
understood term both in RDF and outside RDF, and then back that up with
an informative RDF(S) formalization for those who want it. Those who do
not have RDF(S) reasoners can easily make special purpose code if they
need/want to determine equivalence relationships (which is what Yahoo!
and others usually end up doing when using 'real-world' RDF). You
specify the subclass relationships in the spec and say for 'all
resources of type X, including those with that get type X via subclass
relationship Y, please do Z".

However, simply defining everything only in a way that makes sense to
people who are deeply wedded to RDF will probably kill adoption in many
communities. The same with JSON-LD. The amount of JSON-LD compliant
software is at the moment currently radically dwarfed by the amount of
non-RDF aware JSON processors. So to require full JSON-LD processing
would probably backfire in terms of adoption if it was normative, but
more power to those who use JSON-LD processors (as it will make their
lives easier) and by using it intelligently in the spec we can encourage
people to adopt it without excluding those who haven't adopted an
RDF-centric toolchain.

The model of "let's put my favorite data model in a spec and then
everyone will adopt it" has clearly and unequivocally failed in many
past W3C WGs, not just in terms of RDF but in terms of other data models
like XML.  I'd like to make sure we can get both mainstream adoption of
the API and encourage use of RDF without trying to forcing it down
people's throats (i.e. normatively specifying it) except when absolutely
necessary. Instead, show where RDF has real power with well-defined, and
bind to informatively to encourage adoption. For example, RDF *is*
useful for defining vocabularies and should be used there informatively
when defining a processing model for consuming ActivityStreams.

> 
> it's funny, that's the exact use case i was struggling with recently.
> given that "like" now is defined as a subclass of "respond", i think the
> behavior of a AS ecosystem should be well-defined.
> 
> http://www.w3.org/TR/2015/WD-activitystreams-vocabulary-20150129/#dfn-like
> 
> i would assume that if AS defines "like" to be a subclass of "respond",
> and i am for example trying to track responses in my AS ecosystem, then
> if i say i am interested in responses, the AS fabric will deliver "like"
> objects to me as well, because that's how they are defined by the
> vocabulary. if that isn't the case, then i would frankly struggle with
> the question what it even means that the vocabulary is defined that way.
> 
> now, i think one can go either way and say that yes, a "like" *is* a
> "respond" and should be treated like this, or one could say that this is
> not what happens and if a "like" also should be treated as a "respond",
> and needs to explicitly labeled that way. but whatever happens, it
> should be well-defined and not depend on implementation choices that i
> as an AS user can neither see nor control.
> 
> that was basically what i meant when a while ago, i was asking for an
> explicit processing model in the spec, that would cover exactly these
> kinds of questions. the worst possible outcome from my point of view is
> that we don't specify this, and then end up with implementations
> behaving differently and in ways that are not predictable to somebody
> using AS and not caring about implementation details.
> 
> cheers,
> 
> dret.
>

Received on Monday, 9 February 2015 16:51:26 UTC