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

hello harry.

On 2015-02-09 8:51 , Harry Halpin wrote:
> 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".

you're just kind of right here. i would assume many implementations to 
do what you're saying and implement "reasoning" in whichever way they 
deem appropriate. and that's what a spec should allow people to do: make 
implementation decisions while the spec tells them how their 
implementation must behave.

the tricky part is in the extension model. if i create an activity 
"reallylike" that is a subclass of "like", and i decide to encode that 
in an RDFS document, what happens? is the AS ecosystem expected to 
deliver "reallylike" activities to me when i have a filter somewhere 
that is looking for "respond" activities? as in the "like" case, i think 
we can go either way, but we most important thing is that we have to be 
well-defined.

what's trickier here is that this is not something you can (as easily) 
handle in code (in the way that you described). this requires the spec 
to be explicit in terms of the processing model, and what it *means* 
when extensions are using the same vocabulary mechanisms that the core 
vocabulary is using.

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 Monday, 9 February 2015 17:09:01 UTC