Re: social-ACTION-43: propose *lightweight* inference based on RDFa Vocabulary Expansion (also: ISSUE-12)

hello elf.

On 2015-03-06 15:24, ☮ elf Pavlik ☮ wrote:
> We could look at possibly to have *Lite* and *Full* versions of AS2.0.
> In Lite, one could ignore even this lightweight inference but would have
> less robust construct at hand. Producer would also need to stay more
> explicit if they want *exactly* the same interpretation by Lite consumers.
> Producer who care about same interpretation by *Lite* consumers would
> need to assert "@type": ["Respond", "Like"]
> If Producer accepts *slightly* different interpretation by Lite and Full
> consumers. "@type": ["Like"] would only get interpreted as "@type":
> ["Respond", "Like"] by Full consumers, Lite would miss interred "@type":
> ["Respond"] - IMO reasonable consequence if someone doesn't want to
> implement AS2.0 Full support.

the problem with this model is that i am usually dealing with a SOA with 
a whole bunch of AS producers and consumers in it. it seems that the 
lite/full model would only produce predictable results if all components 
in the SOA implement the same level, and i somehow have a way to find 
out what that level is.

personally, i think we should have one well-defined way of what a "like" 
actually *is*. either it *is* a respond and everybody has to treat it 
accordingly (for the floops this is trickier to get right, because you 
have no way of knowing how the floop has been defined without a formal 
description, which right now we do not have), or it is a like and 
nothing but a like. in all other cases, we create a spec where the 
behavior of the ecosystem depends on local context that i can neither 
discover nor control, and that would be unfortunate.

> Discovery works by simply dereferencing http(s): URI of newly
> encountered term (in practice often already cached). Depending on how we
> decide on AS2.0 serializations, it MUST return application/ld+json
> description of the term (or the whole vocab if # pattern used, as in
> AS2.0 itself), it MAY return text/turtle and text/html (RDFa). Again we
> should discuss Content Negotiation sooner than later.

so what you're saying is that a verb URI MUST be dereferencable, and 
that it MUST dereference to RDF defining that term in a specific way, so 
that all implementations can base their inference on it? that would be 
one way to go, but in this case we would definitely get into "RDF 
required" territory to get an AS ecosystem working.

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 Friday, 6 March 2015 14:35:49 UTC