I'm still not clear about the discussion we had yesterday.
-
I'm still not clear about the discussion we had yesterday. @evan are AS2 (and #ActivityPub) serializations JSON-LD or not? I see the AS2 spec says the serialization only has "“compatibility with JSON-LD” but must conform to JSON-LD algorithm requirements. I understand if it's JSON-LD, it is also JSON (but not necessarily the inverse). Like we discussed yesterday, JSON-LD is JSON and it's an RDF data model. JSON, in general, is neither JSON-LD nor an RDF data model.
-
@steve they're JSON-LD because we needed an extension mechanism.
You can generate RDF triples if you really want. I think quads are even better.
But you can't read those triples to find the secret design intent of AS2. We designed it from JSON down, not from RDF up.
-
Evan Prodromoureplied to Evan Prodromou on last edited by
@steve you were talking about whether activities you receive are "in" your inbox.
It's hard to say "where" a digital object is. In ActivityPub, it's very reasonable to say that the object only truly exists at the URL of its id, and everything else is a copy or reference.
But Collection objects can have JSON objects (copies) and/or URLs (references) in the items array. Saying those objects aren't really "in" the Collection is misleading. Using RDF triples to prove that the aren't is wrong.
-
@evan I understand the extension goal, but how does that work without using JSON-LD processing to expand (disambiguate) terms? In other words, how is extensibility supposed to work for developers using plain JSON?
-
@evan I think we're conflating data models with JSON(-LD) *serialization* of those models and that's going to cause even more confusion. Without RDF, I think it's not going to be easy to discuss whatever abstract data model AP uses.
-
@steve I think trying to define where digital objects *really* are is a fool's errand. When I get an inbox, it has activities in it.
-
@[email protected] there is no extensibility with plain JSON.
Or more specifically there are no guarantees that a property you reference actually refers to what you think, when using plain JSON.
Best you can get is convergence on a property name via popularity, but even then it's a "probably".
-
@steve you put an URL in your context array that says, "I support this extension."
Then, you use terms from that extension.
And, yes, I'm aware it can get a lot more complicated, but it doesn't have to.
-
Evan Prodromoureplied to Evan Prodromou on last edited by
@steve I mean, are apples really "on" your shopping list? No, there is not a pile of fruit on top of the piece of paper. The letters "A-P-P-L-E-S" are not actual apples. They're not even the idea of apples. But saying "I have apples on my shopping list" is useful and meaningful.
-
Steve Batereplied to Evan Prodromou on last edited by
@evan Not necessarily. If you'd like, I can quickly write a simple AP-server that will return a JSON-serialized inbox Collection with URIs in the "orderedItems" array instead of embedded serialized copies of the object referents. It won't interoperate with typical server implementations (Vocata is one exception), although AFAIK it would be conformant with AP/AS2. But again, this is conflating serialization with whatever abstract data model underlies it.
-
Evan Prodromoureplied to Steve Bate on last edited by
@steve ok. The abstract model is, "the objects are in the collection".
-
Steve Batereplied to Evan Prodromou on last edited by
@evan That's not going to handle the same property names in different extensions (without JSON-LD expansion). If that weren't an issue, there could just be an "extensions" property with a list of URIs and JSON-LD could be eliminated completely.
-
Steve Batereplied to Evan Prodromou on last edited by
@evan One can discuss containment without identifying the *real* location of objects (whatever that even means). You seem to be annoyed with this discussion, so I'm going to end my part in the thread now. However, I think it's important (and maybe I'm the only one that feels this way?) to discuss and fully understand these and other confusing aspects of AP/AS2, so don't be surprised to see related posts in the future.
-
Evan Prodromoureplied to Steve Bate on last edited by
@steve I think it's a style issue. You started the thread by saying that collections do not contain AS2 objects. This is untrue, unless you twist the definition of "contain".
-
Steve Batereplied to Evan Prodromou on last edited by
@evan I'm open to style suggestions. However, I still think my original statements are true. I've tried to explain why, but if you have questions, let me know.
-
@julian Sounds right. The idea that AS2 has meaningful extensibility with plain JSON seems like wishful thinking to me.
-
Evan Prodromoureplied to Steve Bate on last edited by
@steve for style, I guess I'd suggest softening language or even asking a question when your statement is counterintuitive and provocative. Instead of "The AS2 container type does not contain objects" maybe "I think the AS2 container type does not contain objects" or "Does the AS2 container type contain objects?" or "What does containment mean in AS2?"
-
Evan Prodromoureplied to Evan Prodromou on last edited by [email protected]
@steve I'm also REALLY oversensitive to any statements about allowed representation of objects in AP. As you probably know better than I, a lot of AP consumers fail to robustly handle id representation or object representation of property values.
-
Steve Batereplied to Evan Prodromou on last edited by
@evan I understand. That's why I said repeatedly that I'm not discussing serialization. I agree that serializing Collections with embedded copies of Objects is needed for interoperability with most existing AP S2S implementations. To clarify, are you concerned about statements related to valid, allowed AP (serialized) representations that aren't the ones typically implemented? Versus invalid representations?
-
Evan Prodromoureplied to Steve Bate on last edited by
@steve so, this is an interesting question. I'd say, as an interoperability standard, AP doesn't make any (well, not many...) assumptions about underlying models. The JSON-LD serialization is all you get; each implementation decides how to manage its own structures internally.