New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How should it be interpreted when a URI value is received? #498
Comments
In general, an IRI for that property should be interpreted like any other valid JSON-LD value for that property. For example, the actor property has a
EDIT: Enter accidentally pressed too early, I'll circle back around to this, to be continued... |
In this case for
So whenever you get an IRI for anything as a property value, treat it literally as an IRI. EDIT: See Example 10 in the JSON-LD spec. Edit 2: This makes your last example's supposition false:
Is invalid, because the IRI for
It is instead incorrectly resolving to the image hosted at Edit 3: This comes back full circle to my first (premature) post: When resolving IRIs instead of embedded JSON arrays/objects, you need to be prepared to handle all the possibilities as dictated by the |
Hello @cjslep, thanks for your response. I'm working on a general-purpose ActivityPub/Stream library too, but in my case using Elixir :) At the same time, I'm creating MoodleNet. Everything is in alpha state: https://gitlab.com/OpenCoop/CommonsPub/Server You said:
Well, I think it is not that easy. If I receive:
I need to know that I think (so maybe I'm wrong here :) it is valid to send just the id instead of the full object specification in all the cases. In fact, it is the spec which decides to send just the ID, a smaller set of data of the object, or the full object data. So, if the above is true, an implementation cannot know beforehand whether the URI is just a URI or an Object ID and it should do a new request to get more information about the object if it's necessary. This happens all the time, I just gave the example of the If my server receives:
And I want to show a photo of this Application, I mean: So I think that using an IRI value to represent a Link could be wrong and a full Link specification should be used:
|
In fact, the |
Your server won't receive that, because it's not a valid ActivityStreams object Using your example:
You cannot put the actual image URL as the "image" property. The JSON-LD Spec permits this property to be an IRI (always). Building on that, the ActivityStreams spec gives the Your server will receive:
And then when you fetch it from the server you'll get anything specified in the Option 1: Image
or Option 2: Link
Do not confuse the JSON-LD concept of IRI, which is a special reference within the linked data structure, and the value of a property which happens to be a URL. |
First of all, thank you very much to take the time to respond me. I really appreciate it :) I have to confess that my knowledge of JSON-LD is very limited. First thing:
It is not my example, it is an ActivityStreams' example. I think this is the source of our confusion. Look at example 11 and 12 here: https://www.w3.org/TR/activitystreams-core/#link It is said that this is valid, and you're saying it is invalid, so we agree. I just wrote that if If this were valid, we'd have a problem. I think you completely understand my point. So I think we are saying the same, that the specs are wrong 😂 |
So the image property can be (with multiple values):
In no case could it be the Link.href directly 👍 |
Holy cow, I didn't even notice that. You're totally right, thanks for setting me straight! |
Hey, just to follow up on this: Figure 11 says: To reference a single image without any additional metadata, a direct association can be expressed as a JSON string containing an absolute IRI. And gives the example:
This is the first example of a Link ever given in the document. I think it should be definitely understood that this is a valid link, considering that it's the prototypical link in the entire spec |
Yes, but I would be careful with the word 'link' as it is not specific enough. The earlier confusion being discussed was whether to interpret it as a That passage in the spec seems to be a very narrow exception to the general rule, one I had missed, and I thank Alex for being patient and explaining it to me. |
@nightpool Sorry, but I could not understand what you mean:
If it is valid, how should a generic implementation resolve the dilemma I tried to explain in #498 (comment) ? What do you mean with prototypical link in the entire spec? Thank you for your time |
@alexcastano here's how I think of it: When you see
Not exactly. And that 'should' is, I'm pretty sure, not aligned with any If you have So what do you "send"? Your conclusion is actually consistent with what I've pointed out here (even though I'm disagreeing with interpreting "url1" as an Practically speaking, It might make sense for an AP implementation to explicitly store a map of URL to cached metadata about what can be dereferenced at each URL (whether you can get an AS2 object at that URL, what content types are available, etc). This would make it less costly to frequently re-dereference the same URLs repeatedly, when any given social we object could be link to dozens of other resources. It would also allow you to do this kind of thing when encountering your .image like
|
Hello @gobengo, thanks for taking the time to answer my question.
My knowledge about JSON-LD is very limited, but AFAIK, you can embed an object or you can just refer to it using its ID. So the @cjslep seems to agree with me in this aspect:
So if the above is true (I repeat I'm not an expert on JSON-LD) the following sentence would be wrong:
And the specification says the same, so it would be wrong as well. And that is the reason because I open the issue. To reinforce the idea that we can take a look at the continues examples we see in the specs:
The difference between example 63 and 64 is how the actor property is represented: first just the id, the second with the embeded object. So if you cannot substitute an Object by its ID I think the specification should make a good explanation about it, because at least I was confused around this idea with the examples. On the other hand, if the substitution of the object by its Just to complete my response, I like to explain that an
So you cannot just put the ID like In closing, I just want to emphasize that my solution to this problem is simply to not allow a |
After some research, came across this section of the JSON-LD 1.1 Processing Algorithms and API.
Here's the way I'm interpreting all this: Activity Streams is inconsistent with regards to the referencing things. It really leans on JSON-LD too heavily to not have to explain JSON-LD things like compaction and expansion. But many examples are quite sus. As far as JSON-LD is concerned, strings with an However there are a few exceptions... The "url" term is annoyingly defined as Further, for terms that specify a Document type, which seems to ONLY be "image" -- TL;DR -- When you get a string for p.s. Interestingly
It should be interpreted as:
You could use this to your advantage for things like the "tag" term, for sure. However, I doubt a lot of servers handle this as such. |
I think the usage of bare |
So, in issue triage, we worked on a primer page on this issue: https://www.w3.org/wiki/Activity_Streams/Primer/URLs_as_values It includes guidance for publishers (don't bare URLs if it could be confusing), and for consumers (use heuristics to guess between Object ID and Link href, with Link id being a very rare property). |
In the primer page it says:
I think that was meant to be "a Link with a href property". |
Please Indicate One:
In core specs, 4.2 Link says:
https://www.w3.org/TR/activitystreams-core/#link
However, in the image property definition, the range is limited to:
Image | Link
My concern is if we have the example 11:
I don't know if
http://example.org/application/123.png
is just aLink
and I can use it directly, or it is anImage
object and that it is itsid
. In the last case, I should fetch the full information of the object to use theurl
property:I think, but I'm not sure, usually when a URI is provided where an
Object
or aLink
should appear means that is anObject
whoseid
is the URI; ie:is equivalent to:
Is this supposition right? Could it mean another thing? Should the implementations have this behavior by default when receiving this kind of messages?
I find confusing this kind of situations where only a URI is received as a value. I'm trying to create an ActivityStreams/ActivityPub generic implementation and this is a stopper in my architecture.
Thank you for your time.
The text was updated successfully, but these errors were encountered: