Re: story or not?

hello elf.

On 2015-02-12 4:44 , ☮ elf Pavlik ☮ wrote:
>> I believe Activity Streams 1.0 at one stage allowed multiple verbs which
>> addressed the issue below fairly simply but provided other complications
>> (and so was removed). With json-ld types, the association is not held in
>> the data itself so it's more complex to process. Definitely think this is
>> an important story.
> Please don't forget that you can use "@type": ["Like", "ex:Yay"] if you
> don't want to depend on inferring it from ex:Yay rdfs:subClassOf as:Like
> statement, which you don't need to use RDFS reasoner to do so but you
> custom code understanding such basic statements.

i do understand that i can explicitly "cast" activities to possibly 
multiple types with constructs such as:

"@type": ["Like", "Floop", "Respond"]

but that to me (and to other people, i would assume) then looks as if i 
MUST do this explicit casting if i want the vocabulary's type hierarchy 
to be reliably represented in my activities.

i am fine doing this if AS2 tells me to do it. what i think is not so 
great is that if i *don't* do it and simply use a single type, then some 
consumers will still interpret this as meaning the above, and some 
don't. taken to the extreme i could then even have a "denormalization AS 
gateway" that would take

"@type": ["Floop"]

activities and rewrite them as

"@type": ["Like", "Floop", "Respond"]

and that would be fine. that would basically be a resolver sitting in my 
ecosystem and doing "reasoning as a service" (RaaS ;-). that's probably 
how we would approach it if the spec stayed like it is. we already have 
a "semantic service" in our platform that's intended to do these kinds 
of things, but the main idea there was always to do value-added 
services, and not to work on core vocabulary issues.

personally, i think that would be a bad design, because we then would 
have to make sure to always pipeline all of our activities through such 
a resolver to get to a consistent interpretation. my hope is the AS2 
will give us a robust model and not require this step to get to one.

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 Thursday, 12 February 2015 16:55:35 UTC