Re: ActivityStreams Schema: Hierarchy of Types

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.

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.

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).

cheers,

dret.

-- 
erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

Received on Wednesday, 12 November 2014 23:50:26 UTC