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

On 03/06/2015 03:35 PM, Erik Wilde wrote:
> 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.
let's all start implementing what we have so far and start producing and
consuming AS2.0, i can implement *Full* with such *lightweight*
inference and you can work with *Lite* without it, then we can see if we
encounter some real issues?

> 
> 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.
i don't like the idea that to keep 'bottom line' low, we don't allow any
more sophisticated patterns!

so far we have one clear example with Respond, Like, Floop
* http://www.w3.org/TR/activitystreams-vocabulary/#activity-types
* http://www.w3.org/TR/activitystreams-vocabulary/#object-types

which I hope to cover with
* rdf:type
* rdfs:subClassOf
* owl:equivalentClass


can we think of examples for properties? eg. participant, endorsee, homeboy
* http://www.w3.org/TR/activitystreams-vocabulary/#properties

which I hope to cover with
* rdfs:subPropertyOf
* owl:equivalentProperty

similar to http://schema.org/participant

current AS2.0 draft doesn't even use such constructs so we could also
start without it!

please notice that I also do NOT propose here any rdfs:domain &
rdfs:range inferences, while Tantek seems to actively ask for it!
ACTION-35 Come up with a simple proposal for implicit typing based on
property names
http://www.w3.org/Social/track/actions/35

> 
>> 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.
if one want's to use just a unique identifier, then can use non
dereferencable URI, or use HTTP URL but don't provide any meaningful
response (Lite)

if one want's to give some additional *meaning* to given type of Verb,
then one needs to use dereferencable URI respond to request with
JSON-LD, and optionally other RDF serializations (Full)

services like https://w3id.org/ can come handy for stable and
dereferencable URIs

it looks like xAPI community starts arriving at such conclusion based on
their work, we may have call next wednesday and I can fwd you invite if
you feel like joining it
https://www.w3.org/Social/InterestGroup/track/actions/5