Remove rel from as:Link #100
Conversation
Per the recent discussions about as:Link, I propose removing the `rel` property from as:Link. It's been pointed out that there are modeling issues in terms of how the rel property semantically relates to the property name. This simplifies things by eliminating the potential conflict.
|
So that goes some of the way but it still keeps the Link object which is no longer needed as explained in To take an example from the spec: currently the Turtle is: <http://example.org/application/123> a as:Application ;
as:displayName "My Application" ;
as:image [ a as:Link ;
as:href <http://example.org/application/123.png> ;
as:mediaType "image/png"
] .Why not instead do the simple thing, namely <http://example.org/application/123> a as:Application ;
as:displayName "My Application" ;
as:image <http://example.org/application/123.png> .
<http://example.org/application/123.png> as:mediaType "image/png" . |
|
If that's what you want to do the spec allows it. |
|
I am still trying to understand why |
|
ok, I see that we are moving in the right direction with the new examples. But it is not quite work right for content negotiated resources. Imagine I am writing a JavaScript client and I want to display an image for an application, but I want my JavaScript to work on all browsers with minimal effort - that is I don't want to keep for each browser a list of types of preferred mime types it supports. So I'd like to just be able to follow the as:image relation and get the URL of the content negotiated resource. The following is allowed by your current spec and is great for that: </application/123> a as:Application ;
as:displayName "My Application" ;
as:image </application/image> .Here I can follow the Now I suppose the Link type is needed for clients that know a lot more about the browser they are working in and that can choose the specific representation. If as a AS2.0 publisher I want to use the current proposed spec to also cater to those client I'd want to do the following: </application/image> a as:Link;
as:href </application/image.png>;
as:mediaType "image/png" ;
as:href </application/image.jpeg> ;
as:mediaType "image/jpeg" .But since RDF triples are not ordered that would be equivalent to the following: What this shows is that there is no way to specify the mime types for the particular representation. This is because in a graph format we have the following.
But what we really need is that the mime type be attached to the final representation resource not the content negotiation one. Like this:
And indeed RFC 5988 the Web Linking Spec confirms this with the following text:
|
|
Note that all of that makes more sense when one removes the legacy ontology elements that try to mimic the atom
One should be careful when modelling things not to get mislead by syntax. It makes modelling a lot more complicated, the advantages are short lived - syntax fashions change - and it makes the whole code more complex. |
|
That's not how it currently works. One, href and mediaType are defined as functional properties of as:Link. Two, it would be more like: {
"@id": "http://example.org/application",
"@type": "Application",
"image": [
{
"@type": "as:Link",
"mediaType": "image/jpeg",
"href": "http://example.org/application/image.jpeg"
},
{
"@type": "as:Link",
"mediaType": "image/png",
"href": "http://example.org/application/image.png"
}
]
}Which translates down to: Which is exactly what one would expect. |
In which case the problem is: how do you deal with content negotiated resources? To develop this further: I was trying to get you to consider the case where there is one image with a number of different content negotiated representations - which is what web architecture enables for the sanity of all developers. So if you don't allow that, you don't allow something pretty important for the system we are trying to build, and one that LDP is constantly using. Hence the SWWG issue-14 on "as:Link complexity" which you argued should be closed for lack of details. So I am providing arguments here as to why it is not just complex but does not answer an important need. Another way to put the question is: does <application> as:image _:b0.
_:b0 as:href <image.jpg> .
_:b0 as:mimeType "application/jpeg" .then it has to be possible to replace the blank node <application> as:image <image> .
<image> as:href <image.jpg> .
<image> as:mimeType "application/jpeg" .Assume the following is true of
Then we have to arbitrarily choose one of the content negotiated representations as the object of your
If Note that this won't be the case just for the objects of the Now as I think there are a number of reasons why you ended up in this conundrum, which I think can be explained in part by the tension you feel between making an ontology and thinking also about how it will look in one of the preferred formats. But we have to do here a job of reverse knowledge engineering to extract the semantics behind the original format of Atom XML, by considering its use, and this type of work can lead to some unexpected conclusions. But luckily the way you have modelled the atom <entry>
<title>Atom draft-07 snapshot</title>
<link rel="alternate" type="text/html"
href="http://example.org/2005/04/02/atom"/>
<link rel="enclosure" type="audio/mpeg" length="1337"
href="http://example.org/audio/ph34r_my_podcast.mp3"/>
<id>tag:example.org,2003:3.2397</id>
<updated>2005-07-31T12:29:29Z</updated>
<published>2003-12-13T08:29:29-04:00</published>
...
</entry>can be modelled differently as I argued in issue #98 "removing the as:Link element. If one considers it carefully I argued there, these are just reifications that we no longer need to use. But I won't repeat here what I wrote there yesterday. |
|
@bblfish do you see any issue with as:Collection allowing as:Link instances as its items (usually blank nodes)? I also now notice as:items defined as owl:FunctionalProperty which confuses me. (ignoring for now historical use of plural name for property...) as:items a owl:ObjectProperty,
owl:FunctionalProperty ;
rdfs:label "items"@en ;
rdfs:domain as:Collection ;
rdfs:subPropertyOf prov:hadMember ;
rdfs:range [
a owl:Class ;
owl:unionOf (
[
a owl:Class ;
owl:unionOf ( as:Object as:LinkNotHandler )
]
as:OrderedItems
)
] .
as:LinkNotHandler a owl:Class ;
rdfs:label "Links that are Not Handlers"@en ;
rdfs:subClassOf as:Link ,
[ rdf:type owl:Class ;
owl:complementOf as:ActivityHandler
] ;
rdfs:comment "Represents instances of as:Link that are not also as:ActivityHandler"@en .http://www.w3.org/TR/activitystreams-vocabulary/#non-normative-ontology-definition |
|
@elf-pavlik that looks like another issue. I opened a link to it here: #104 |
|
Issue resolved on the call: Maintain current status quo and keep rel |
Per the recent discussions about as:Link, I propose removing
the
relproperty from as:Link. It's been pointed out that thereare modeling issues in terms of how the rel property semantically
relates to the property name. This simplifies things by eliminating
the potential conflict.