Re: ActivityStreams Schema: Hierarchy of Types

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 00:12:37 UTC