Re: extension model of RSS/Atom (ISSUE-16 discussion)

hello elf.

On 2015-04-13 04:03, ☮ elf Pavlik ☮ wrote:
> On 04/13/2015 05:58 AM, Erik Wilde wrote:
>> i am not arguing that the spec does not map what's in the spec. i am
>> pointing out that per the current spec mapping cannot be done in all
>> cases because no context is required for extensions, and JSON-LD is not
>> a required processing model.
> To my understanding
> * NOT required: http://www.w3.org/TR/json-ld-api/
> * required: http://www.w3.org/TR/activitystreams-core/#compact-iris
> where Handling of JSON-LD Compact IRIs requires information from the
> @context.

are these "JSON_LD Compact IRIs" different from CURIEs? for now i am 
assuming they're not; if they are, some clarification about the 
differences would be very welcome.

afaict, AS2 simply disallows a couple of CURIE prefixes so that things 
do not get to messy. this is where the hardcoded magic comes into play. 
i don't think this has anything to do with extensions. it simply makes 
sure that the implicit hardcoded contexts do not get confused by people 
using full JSON-LD (where prefixes are unrestricted).

<TL;DR>

this is actually one more wonderful analogy with XML. in XML, namespace 
prefixes are part of the infoset, but processing XML based on prefixes 
is considered a bad antipattern. it is generally accepted that any spec 
that hardcodes them is broken. there are very good reasons for this, and 
i am assuming they apply in the same way to JSON-LD and AS2.

</TL;DR>

> Last but not least, I see JSON-LD @context providing standardized way to
> address *describe data using URIs* requirement from WG charter:
> "A transfer syntax for social data such as activities (such as status
> updates) should include at least the ability to describe the data using
> URIs in an extensible manner, time-stamping, and should include a
> serialization compatible with Javascript (JSON) and possibly JSON-LD."

in really have no issues with using JSON-LD as a databinding into a 
metamodel that the majority of the WG prefers. what i am wondering about 
how well that will work out when the spec is set free into the world 
where most people have different metamodel preferences, and will happily 
throw into the format the simplest possible structure that it allows.

> Would you suggest some other, preferably standarized, ways than JSON-LD
> @context for using URIs in JSON? Especially for object *keys*
> (property/predicate) and not only values (object) (of course value of
> "@id" denotes triples subject, EAV/SPO).
> Since charter states "possibly compatible with JSON-LD" I think we
> should provide strong technical reasoning, which clearly explains what
> makes it not possible to stay compatible with JSON-LD!

we need rules, demos and tests:

- showing how JSON-LD compliant AS2 can be read by implementations and 
reported to applications that are not using a JSON-LD toolchain. the 
results should be consistent and predictable.

- showing how non-JSON-LD compliant AS2 can be read by implementations 
and reported to applications that are using a JSON-LD toolchain. the 
results should be consistent and predictable.

- we also need to show that those two scenarios can interoperate.

> What kind of JSON data and not 'based on' JSON-LD we need to support?
> * no JSON-LD @context at all
> ** publisher can't use Compact IRIs (PROPOSAL: just use full IRIs?
> similar to https://tools.ietf.org/html/rfc5988#section-5.3)

right now we're saying "anything". that's a far cry from requiring 
CURIEs or URIs.

> If you can provide some sample data we could make this conversation more
> concrete and include that data in our test suites.

once we have friendly tests i'll happily take those and turn them into 
tests that plain JSON developers will create: no context, no CURIE, no 
URI, simply property names with short names. possibly arrays. all the 
stuff where somebody expecting to just turn the JSON-LD crank and get 
some RDF out of it will simply not get anything.

>> - there are well-defined expectations what infoset-based techs should
>> make available to applications, and that seems to work well.
> Thank you for this additional elaboration. What do you see as a drawback
> of what I understood as a shift towards making XMLNS and infoset a
> requirement?

not much, because people preferred it. but it was a clear and clean 
definition, and all subsequent specs clearly said: *only NS-compatible 
XML allowed*. some people still dislike it, but people have adapted. but 
the consequence is that any non-NS XML today pretty much is 
unprocessable. XPath won't work, XSLT won't work, XQuery won't work, and 
most XML APIs won't work as well.

>> i have yet to see any proposal how apart from magic hardcoded mapping
>> rules based on JSON-LD contexts, AS2 will robustly handle extensions
>> that are not conforming to JSON-LD. i guess we'll see once we have test
>> cases exploring that end of the format spectrum, and making statements
>> about what should be made available to applications and how.
> I don't understand what you mean by "magic hardcoded mapping rules based
> on JSON-LD context". I see those mappings *machine readable* first of
> all, even while not supporting all JSON-LD Processing Algorithms.

they look like hardcoded into the spec to me, not machine-readable. if 
they were machine readable, there would be no need to hardcode prefixes, 
right?

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 Tuesday, 14 April 2015 02:34:57 UTC