- From: James M Snell <jasnell@gmail.com>
- Date: Tue, 22 Jul 2014 10:15:59 -0700
- To: Owen Shepherd <owen.shepherd@e43.eu>
- Cc: public-socialweb@w3.org
There's a balance here. See below. On Tue, Jul 22, 2014 at 9:50 AM, Owen Shepherd <owen.shepherd@e43.eu> wrote: > Why do we even have a rel property? I don't see any use of it which couldn't > be more succinctly expressed by using the property name. It also breaks > JSON-LD processing, by conflating a property of the link (the relation) with > the object. > Imagine the following case. I have a objectType that represents an application. As is typical in many "app stores", the application may have multiple preview images with a single default or preferred preview. We can accomplish this concisely using something like: { "objectType": "application", "displayName": "My Application", "preview": [ { "mediaType": "image/jpeg", "url": "http://example.org/screens/app1.jpg" }, { "mediaType": "image/jpeg", "url": "http://example.org/screens/app2.jpg" }, { "mediaType": "image/jpeg", "url": "http://example.org/screens/app3.jpg", "rel": "image" } ] } Here, the third image is set up as both a preview image and the default display image for the object. > I'm with you in being against a generalized url property; this is why I > want to see its' purpose defined. I very much want an easy to extract > property to which I can link a user so that they can view the object on its' > "home site". This is very much an important feature of the format, no? > If I had my choice, the generic "url" property would be deprecated in favor of a specific Link Relation, such as "self" or "canonical". { "objectType": "image", "self": "http://example.org/foo.jpg" } Is semantically clear and tell's me exactly what I need to know without the need to overload "url". > AS1 defines the url property to have this purpose. Why change it? What was > wrong with it as is, except for the "misuse" of it by the Media Link and > Collection types? > > Also, I wholeheartedly disagree with your use of the "self" relation to > point to the image file. To quote RFC 4287: > > 3. The value "self" signifies that the IRI in the value of the href > attribute identifies a resource equivalent to the containing > element. > > There is also already precedence for using the self relation to point to > the ActivityStreams version of an object in AS1. > > Is there any compelling argument *against* defining a property to contain a > link to the (image|video|audio files) which define a resource? Consider the > property's values as analogous to the HTML5 <source> element > The main argument that I can see is that we just end up duplicating the existing function of Link Relations. Why do so when we can reuse an already paved path? - James > > From: James M Snell [mailto:jasnell@gmail.com] > Sent: 22 July 2014 16:52 > To: Owen Shepherd > Cc: public-socialweb@w3.org > Subject: Re: AS2 links > > The linking model within AS2 allows existing RFC5988 Link Relations to be > used directly as attributes on AS objects (see > http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2.html# > linkValues). This means that we can already directly adopt existing link > relations such as "self" and "alternate" to do what you are suggesting. > Objects used as link values can also have a "rel" attribute that explicitly > specifies the relation. > > So, for instance, with the spec as currently written, we can do: > > { > "objectType": "image", > "id": "http://example.org/api/image/sdashdkj", > "url": [ > { > "url": "https://example.org/api/image/sdashdk/thumb.jpg", > "mediaType": "image/jpeg", > "width": 128, > "height": 128, > "rel": "preview" > }, > { > "url": "https://example.org/api/image/sdashdk/image.jpg", > "mediaType": "image/jpeg", > "height": 1024, > "width": 1024, > "rel": "self" > } > ] > } > > Or, we can simplify that down to: > > { > "objectType": "image", > "id": "http://example.org/api/image/sdashdkj", > "height": 1024, > "width": 1024, > "mediaType": "image/jpeg", > "self": "https://example.org/api/image/sdashdk/image.jpeg", > "preview": { > "url": "https://example.org/api/image/sdashdk/thumb.jpg", > "mediaType": "image/jpeg", > "width": 128, > "height": 128 > } > } > > Either would be valid under the current spec with the latter being > preferred over the former. Ultimately, I would much rather see more direct > use of the registered Link Relations (as in the second example) and less use > of the more generic/generalized "url" property. > > - James > > On Tue, Jul 22, 2014 at 8:29 AM, Owen Shepherd <owen.shepherd@e43.eu> > wrote: > ActivityStreams 1.0 largely defines the precedence of using the “url” > property as a link to a “user viewable” version of the object (e.g. a http > link to a web page which represents the object): > url > JSON [RFC4627] String > An IRI [RFC3987] identifying a resource providing an HTML representation of > the object. An object MAY contain a url property > (The use HTML here is probably overly restrictive, but the intent is clear) > > It makes some missteps: > • For media links, url is the IRI of the media resource (e.g. an > image) > • For collections, url is the IRI of a the collection in JSON form. > This is contradictory to the above, as collections are objects > > These are best interpreted as bugs in the spec, IMO. > > The AS2 ED defines url as follows: > url > Link Value > A Link Value describing a resource providing a representation of the > object. An object MAY contain a url property. > > This provides no context for what the “url” property actually points to. > The examples in the spec then use the “url” property to refer to multiple > different resources: a web page representing a user, the actual image in the > case of an “image” object, etc. The “url” property provides no useful meta > data with regards to what its’ pointing to. This is useless. > > I suggest that we split the two conflated roles into two separate > properties: > • url: The IRI of a resource which represents a human readable > representation (for example, a HTML document) of this object > • href? src?: A link value containing one or more machine > processable representations of this resource. For example, for an object of > type image, this could provide multiple resolution images of the object > • We might also codify self, The IRI at which the JSON form of this > resource can be found. This would simply be codifying use of the already > defined link relation for this purpose. > > We might add language to the spec as follows: > • The id of an object SHOULD be the IRI of a resource which can be > dereferenced to return an up to date description of the object in this > format. > • In cases where the id does not correspond to an IRI > dereferencable as above, then the object SHOULD contain the self property, > set to an IRI which may be dereferenced for an AS2 representation of the > object. > • In the absence of values for the url and href properties, > processors MAY attempt to dereference the IRI that is the object’s id for > the resources to which these properties would normally point. This means > that you can just put the URI of an image in an Object’s image property and > things will still work; no need to actually construct an image object. > Obviously in this case it may not really be possible for clients to interact > with the image as a discrete entity. > > This actually has brought me back around to thinking that the AS1 concept > of a media link was correct, just incorrectly applied. I feel that they’re > actually very useful, but were expressed incorrectly in AS1. The importance > of such objects is in sufficiently expressing the semantics of the data: if > all the resolution variations of an image become independent objects, then > what you have is not a meaningful object graph, but rather an object soup > > AS1 example: > { > “objectType”: “image”, > “id”: “https://example.com/api/image/sdashdkj”, > “url”: “https://example.com/person/image/sdashdkj”, > “image”: { “src”: “https://example.com/api/image/sdashdkj/image.jpg” > } > } > > Proposed AS2 example: > { > “objectType”: “image”, > “id”: “https://example.com/api/image/sdashdkj”, > “url”: “https://example.com/person/image/sdashdkj”, > “href”: [{ > “src”: “https://example.com/api/image/sdashdkj/thumb.jpg”, > “mimeType”: “image/jpeg”, > “width”: 128, “height”: 128 > }, { > “src”: “https://example.com/api/image/sdashdkj/image.jpg”, > “mimeType”: “image/jpeg”, > “width”: 1024, “height”: 1024 > }] > } > > >
Received on Tuesday, 22 July 2014 17:16:46 UTC