Subject: link confusion?

From: Henry Story <[email-masked]>
Date: Fri, 25 Mar 2005 17:36:43 +0100

I was trying to interpret the spec link element and found it a little 
confusing.

If I try to look at the spec in a simple relational way (what is being 
related to what?)
then, given the following example xml,

   <entry>
     ...
	<link href="http://bblfish.net/blog/page5.html#42"
           type="text/html"
           hreflang="en"
           length="450"
           title="The html entry"
           rel="related/>
    </entry>

  I would initially draw a diagram such as this

_e1--is-a--> <Entry>
   |--link--> _link
                |--href--> <http://bblfish.net/blog/page5.html#42>
                |--type--> "text/html"
                |--lang--> "en"
                |-length-> 450
                |-title--> "The html entry"
                |--rel---> "related"

But that does not seem quite right. There seems first of all to be a 
confusion
about properties related to the link, and properties related to the 
thing the link
is linking to. For example the length, type and hreflang attributes are 
about the
resources pointed to by the link, whereas the rel and title attributes 
are relations
describing the link.

So a better interpretation of the initial xml would be the following

_e1--is-a-> <Entry>
  |--link-> _link
           |--to---->_r--is-a-> <Representation>
           |         |--href--> <http://bblfish.net/blog/page5.html#42>
           |         |--type--> "text/html"
           |         |--lang--> "en"
           |         |-length-> 450
           |-title--> "The html entry"
           |--rel---> "related"

  We know that the thing that link is linking _to_ is not a resource but 
a
representation because we have specified the mime type, length and 
language of
the thing linked to, and these are properties of representations, not
resources. A resource as we all know can have many representations, not
only over time, but at the same time.

So the above graph would seem to capture much better what we are trying 
to
relate to what. By doing this I think it becomes much easier to 
understand
what is happening with the link element, and so also to extend it 
properly.

But if this is a correct interpretation of what is happening then 
perhaps
this should also be clearer in the xml itself. Would the following 
perhaps not
be a little better then:

  <entry>
     ...
	<link title="The html Entry" rel="related">
		<representation
         	href="http://bblfish.net/blog/page5.html#42"
          	type="text/html"
             lang="en"
             length="450"/>
     </link>
  </entry>

It would at least then be possible to see how one can have a
certain type of link to multiple representations (perhaps different
language version of the entry for example)

  <entry>
     ...
	<link title="The html Entry" rel="related">
		<representation
         	href="http://bblfish.net/blog/page5.html#42"
          	type="text/html"
             lang="en"
             length="450"/>
		<representation
         	href="http://bblfish.net/blog/de/page5.html#42"
          	type="text/html"
             lang="de"
             length="664"/>
     </link>
  </entry>

It would at least seem to be differentiating better between the two
elements that are currently muddled in the link construct, and may even
open up some interesting possibilities.

Henry Story

---

From: Henry Story <[email-masked]>
Date: Fri, 25 Mar 2005 21:32:49 +0100

On 25 Mar 2005, at 17:36, Henry Story wrote:
> given the following example xml,
>
>   <entry>
>     ...
> [snip]

Another interpretation of the original xml which would take into 
account the fact that
a link MUST have an href element would be:

_e1--is-a-> <Entry>
  |--link-> _link
           |--href--><http://bblfish.net/blog/page5.html#42>
           |         |--representation-->_r
           |                             |--type--> "text/html"
           |                             |--lang--> "en"
           |                             |-length-> 450
           |-title--> "The html entry"
           |--rel---> "related"

which is saying that a link relates an entry and a resource, and that 
sometimes
it is appropriate to give extra information about representations of 
that resource.

And so more it would perhaps be clearer for the xml to be stated like
this

<entry>
     ...
	<link title="The html Entry"
           rel="related"
           href="http://bblfish.net/blog/page5.html#42">
		<representation        	
          	type="text/html"
             lang="en"
             length="450"/>
     </link>
  </entry>

I am not saying that that is the answer, just that the it may help to 
make the
distinction clearer somehow between properties of the link and 
properties on the
object of the link.

Henry

---

From: Henry Story <[email-masked]>
Date: Tue, 29 Mar 2005 15:22:54 +0200

I was trying to interpret the atom:link element [1]

If I try to look at the spec in a simple relational way (what is being 
related to what?)
then, given the following example atom xml extract,

   <entry>
     ...

One may think of representing this with the following N3

[ a :Entry;
   :link [ :href <http://bblfish.net/blog/page5.html#42>;
           :type "text/html";
           :lang  "en";
           :length "450";
           :l_title  "The html entry"; # see note [2]
           :rel    :alternative
         ]
].

The problem to my mind is that the above interpretation of the xml is 
confusing
relations that apply to the link (:rel, :l_title) and relations that 
apply
to the object of the link (:type, :lang, :length).

Hence I prefer the following

@prefix arch: <http://sw.nokia.com/WebArch-1/>
@prefix owl: <http://www.w3.org/2002/07/owl#>

[ a :Entry;
   :link [ :href [ owl:sameAs <http://bblfish.net/blog/page5.html#42>;
                   arch:representation [
                   				   :type "text/html";  # note [3]
                                    :lang  "en";
                                    :length "450"
                                   ]
                 ]
           :l_title  "The html entry"; # see note [2]
           :rel    :alternative
         ]
].

That seems quite good.

Now the interesting thing is that from the above it would seem that one
should be able to deduce the following:

[ a :Entry;
   :alternative [ owl:sameAs <http://bblfish.net/blog/page5.html#42>;
                  arch:representation [
                   				   :type "text/html";  # note [3]
                                    :lang  "en";
                                    :length "450"
                                   ]
                 ]
].

Ie. the link object is not really an object, but as its name suggests
is really a relation. This would not be such a problem except for the 
fact
that we have now lost the title information that was placed on the link
object.

So perhaps what we have is that the link object is an anonymous 
rdfs:SubPropertyOf
the object of its :rel relation (in our example :alternative) which has 
a special
title attribute. That would allow us to make the above deduction I 
think.

So if variable relations were allowed  (they may be in N3, I am not 
sure),
one could write

[ a :Entry;
    _:link [ owl:sameAs <http://bblfish.net/blog/page5.html#42>;
             arch:representation [
                   				   :type "text/html";  # note [3]
                                    :lang  "en";
                                    :length "450"
                                  ]
          ]
].
_:link :rel :alternative;
        :l_title  "The html entry".

where :rel is itself a rdfs:SubPropertyOf rdfs:SubProperty.

This may make the atom link relation clearer to some :-)

Henry Story

[1] http://www.atompub.org/2005/03/12/draft-ietf-atompub-format-06.html
[2] the title attribute of the link is called l_title to avoid 
confusing it with the
  title element of the entry
[3] I am surprised the web arch ontology does not have the vocabulary 
for
    :type, :lang and :length that atom has.

---

From: Henry Story <[email-masked]>
Date: Wed, 30 Mar 2005 12:32:36 +0200

On 30 Mar 2005, at 08:44, Jeremy Wong wrote:
> I am not going to reply your message in details. Just a note of my 
> feeling that your first representation is simple, while the structured 
> representations are complex. A simple representation favours 
> searching, while a complex representation retards a search.

I think that depends on what tools you are using for search. For 
example with BlogEd
I am using a Java interfaces to surf the triple base (that's a little 
what if feels
like :-) With the following code:

------------8<------------------------------------------------------
public interface AtomEntry  {
     String BASE = AtomEntryID.BASE;
     String LINK_BASE = "http://www.iana.org/assignments/relation/";
     String RDF_TYPE = BASE + "Entry";

     /**
      * An entry can have any number of contributors
      */
     String RDF_contributor = BASE + "contributor";
     AtomPerson addContributor(AtomPerson person);
     Collection<AtomPerson> getAllContributor();

     ...

    /**
      *  get all alternate representations of this entry
      */
     String RDF_alternate = LINK_BASE + "alternate";
     void addAlternate(URI link);
     Collection<URI> getAllAlternate();

     ...
}
------------8<------------------------------------------------------

It will be easier to get the alternate links as it will be just one
method call away. What my previous reasoning allows me to do is
to think of the <http://www.iana.org/assignments/relation/alternate>
relation in a way that would (if correct) make the above java correct.

I am happy with the part of the argument that allows me to think of
iana:alternate as a relation between an Entry and something. What I
am still not quite clear about is what that something really is. Is it
a URI (as expressed in the example code above), or is it a 
representation,
or is at representation-URI combination? What is the alternate thing we
are pointing to?

I am starting to think that there is no way of telling really since 
these
things are completely under-specified by atom. I think one will have to 
wait
for the usage that is made of these and work out from there what people
really mean by these terms.

As such the safest may be for an aggregator to work with the
first definition and use inferencing to reach the others when the 
situation
is clearer.

As I am currently writing an editor I can be a little more flexible and
use a more private interpretation of these things. (though perhaps I 
should
not use the iana:alternate uri.)

Henry Story

>
> Jeremy
>
> ----- Original Message ----- From: "Henry Story" 
> <[email-masked]>
> To: <[email-masked]>; "'SWIG'" <[email-masked]>
> Cc: "bloged" <[email-masked]>; "'Atom Syntax'" 
> <[email-masked]>
> Sent: Tuesday, March 29, 2005 9:22 PM
> Subject: atom link analysis - was: link confusion?
>
>
>>
>> If I try to look at the spec in a simple relational way (what is 
>> being related to what?)
>> the object of its :rel relation (in our example :alternative) which 
>> has a special
>> [1] 
>> http://www.atompub.org/2005/03/12/draft-ietf-atompub-format-06.html
>>> which is saying that a link relates an entry and a resource, and 
>>> that sometimes
>>> <representation        type="text/html"
>>>             lang="en"
>>>             length="450"/>
>>>     </link>
>>>  </entry>
>>>
>>> I am not saying that that is the answer, just that the it may help 
>>> to make the