Re: ActivityStreams Schema: Hierarchy of Types

Requiring an RDF world view would be a mistake. Use of JSON-LD does
not require us to take that view. It does, however, enable those who
want to take that view to do so. A minimal vocabulary based around the
most common use cases, defined within the
www.w3.org/ns/activitystreams namespace makes sense to enable a
minimal level of interop. If someone wants to bridge those definitions
into other vocabularies/systems, there's nothing stopping them from
doing so. That said, in order to define that minimal vocabulary, we
need a minimal set of basic use cases from which to build around. The
work that Erik has been doing looking at the AS1 base schema is a
great start.

On Wed, Nov 12, 2014 at 4:10 PM, ☮ elf Pavlik ☮
<perpetual-tripper@wwelves.org> wrote:
> On 11/13/2014 12:51 AM, Erik Wilde wrote:
>> hello elf.
>>
>> On 2014-11-13, 00:24, ☮ elf Pavlik ☮ wrote:
>>> I would say that we can base it on RDF data model so *those who chose
>>> to* can take full advantage of it. Still if someone *chooses to* ignore
>>> @context, then this implementation will treat the data as plain old
>>> JSON, which uses unmapped strings. Constructs like "@type": ["Person",
>>> "foaf:Person"] and similar don't force anyone to treat them as RDF.
>>
>> this is a very slippery slope and at the very least we should be open
>> and honest about how steep we are making that. for example, just in your
>> short snippet, "foaf:Person" already makes assumptions about the prefix
>> "foaf:" (what's the processing model to find out what that's supposed to
>> mean?), and thus you cannot simply treat that as a string.
> Implementation which doesn't process it as RDF, would see "Person" and
> recognize it as one of AS basic types (it also completely ignores what
> @context maps it to), then it sees "foaf:Person" and doesn't recognize
> it so doesn't act upon it but just leaves it there in case some other
> implementation at some point will understand it.
>
>>
>> i don't think there's an easy way around this. either we say "AS is
>> JSON" and then basically all "AS to RDF" mappings could be safely
>> removed from the spec and put into a "processing AS as RDF" spec. or we
>> say "AS is RDF (with JSON-LD as the required serialization)" and then
>> implementers know what to expect.
> How about "As uses RDF model, but one can use it in its compacted form
> as JSON and ignore RDF". It may only have few minor limitations by lack
> of support for some JSON features like array of arrays (anything else?).
>
>
>>
>> AS would be the first-ever spec to successfully avoid the conundrum that
>> you have to pick your foundation, and then play according to its rules.
>> i think AS can pick either way: to be JSON and outsource RDF mappings to
>> additional layers, or to be RDF (in its JSONish form of JSON-LD) and
>> tell people to use RDF toolsets or face the trouble of basically
>> re-implement them. i've heard people sounding hopeful that this choice
>> could be avoided, but i have yet to see any evidence that that's
>> possible (except for the variant where the spec is unclear about its
>> processing model and then interoperability is compromised).
> Assuming that we base it on RDF model, could you provide some examples
> where someone MUST use RDF toolset to process it and can't just treat
> data in compacted form as plain JSON?
>

Received on Thursday, 13 November 2014 15:54:55 UTC