Subject: Re: What is this entry about?

From: Danny Ayers <[email-masked]>
Date: Sat, 12 Nov 2005 10:26:39 +0100

Sorry Bill, only just noticed this - overactive Gmail filters...

On 10/22/05, Bill de hÓra <[email-masked]> wrote:
> James M Snell wrote:
> > Bill de hÓra wrote:
> >
> >>> For instance, suppose that I want to
> >>> indicate that an entry is about http://www.ibm.com and file that in a
> >>> category called technology?  The categorization of the entry is
> >>> different than the subject of the entry.. tho both are definitely
> >>> related.
> >>>
> >>
> >>
> >> There are two distinct forms of discourse going on here
> >>
> >> - This entry is talking about some subject area or entity or resource.
> >> It says something about something else. Being able to do this pretty
> >> much why RDF was invented.
> >>
> >> - This entry is classifiable under some subject area or topic or class.
> >> It has something has sense of belonging or association to something
> >> else. Being able to do this is pretty much why Topic Maps were invented.
> >>
> >> Please, please, please, do not conflate these.
> >>
> >>
> >>
> > Oh absolutely, I'm not trying to conflate 'em.  I want to find a
> > solution to the first case ("this entry is talking about some subject
> > area") that preferably does not involve invention or abuse of existing
> > formats/tags.  I'm more than aware that RDF does this already but I not
> > sure how that fact helps us in Atom (which is not RDF).
>
> [RDF and TM were exemplary; cc'd to Henry/Danny]
>
> Ah ok; I had read the proposal initially as subject classification
> (dc:subject had me thinking that way).
>
> If you're looking for a way to say this is entry is saying stuff about
> something over there, then dc:subject and atom:category aren't a good
> fit as they're more or less pointing the wrong way. rdf:about is the
> closest analog in semweb land (plus it takes urls), but it's the wrong
> thing here (I'll get to this).
>
>  You could do any of the following:
>
>  - define an atom:about tag or attribute that takes a URL.
>  - use a @rel=about on a link tag
>
> You can't use an rdf:about on the atom:entry element for this and that's
> to do with entry metadata associations. What we want to say is that the
> entry to talking about something else. With rdf:about the entry
> *metadata* will become bound to the something else and not the entry
> (which is messed up). The only sensible way I see is to work in terms of
> the entry URI and the URI you're pointing at: 'entryURI isabout
> someOtherURI' and define a new term for this purpose. Anyone that wants
> to model this formally has enough information in the entry markup to
> consistently generate the correct RDF statements out of band.
>
> [I'm not suggesting RDF stuff for this - it's just very useful for
> teasing out issues]

(I've cc'ed the atom-owl list, this is certainly in scope over there).

I think Bill's right about the direction being the issue, and has
probably got the right answer with adding another property to the
entryURI, but there's a fair bit of devil in the detail.

There's a slight mismatch between Atom's id and resource
identification in the RDF sense (Henry, you've looked at this hardest
- please correct me if I'm wrong). Entries can appear with different
values but the same id, e.g.
[[
If multiple atom:entry elements with the same atom:id value appear in
   an Atom Feed Document, they represent the same entry.  Their atom:
   updated timestamps SHOULD be different.
]] 4.1.1

So if  atom:id is treated as the entry resource URI then in a literal
RDF interpretation of the Atom spec you either end up with information
loss, older versions of the entry ceasing to exist (which doesn't
really work with either Atom or the RDF model) or contradictions, e.g.
more than one content value for an entry when the properties of the
resources are lined up together.

The way we got around this in Atom/OWL is to make the entry itself a
blank node, with atom:id being a property of it. The unique
identification of the entry node being provided by the combination of
the id, updated (and some other stuff - multiple language support is a
complication). This seems to work pretty well for most purposes - an
application could either take the "forget older entry versions"
processing model, or accumulate all the versions. But when it comes to
saying what the entry in about, I think you'd almost certainly expect
all *versions* of an entry to be about the same thing, so the subject
of the statement would be the id URI. This is easy enough in RDF (the
id is a resource), but it's not obvious how this migght be expressed
in Atom syntax.

So in short I'd say "what Bill said", and then run away...

Cheers,
Danny.

--

http://dannyayers.com

---

From: Henry Story <[email-masked]>
Date: Sat, 12 Nov 2005 12:48:56 +0100

On 12 Nov 2005, at 10:26, Danny Ayers wrote:
> [snipped a very good conversation]
>

yes. Very well explained. I'll just fill out the details again below,
for those who may be new to this [1]. If you take the example

<entry>
        <title>Atom-Powered Robots Run Amok</title>
        <link href="http://example.org/2003/12/13/atom03"/>
        <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
        <updated>2003-12-13T18:30:02Z</updated>
        <summary>Some text.</summary>
</entry>

you DON't want to model it as:

<urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a>
            :title "Atom-Powered Robots Run Amok"^^xsd:string;
            :updated  "2003-12-13T18:30:02Z"^^xsd:date .

because if a feed contained a correction of the above entry say

<entry>
        <title>Atom-Powered Robots Run Amok in France</title>
        <link href="http://example.org/2003/12/13/atom03"/>
        <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
        <updated>2005-12-13T18:30:02Z</updated>
        <summary>Some updated text.</summary>
</entry>

then you would have

<urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a>
            :title "Atom-Powered Robots Run Amok in France"^^xsd:string;
            :updated  "2005-12-13T18:30:02Z"^^xsd:date .

And so by smushing the graph you would end up with something that was  
not
very useful such as

<urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a>
            :title "Atom-Powered Robots Run Amok"^^xsd:string;
            :title "Atom-Powered Robots Run Amok in France"^^xsd:string;
            :updated  "2003-12-13T18:30:02Z"^^xsd:date .
            :updated  "2005-12-13T18:30:02Z"^^xsd:date .

And you would no longer know which title belonged with which updated  
time
stamp.

> complication).

Yes.  The correct way to model it is therefore

[] a :Entry;
      :title [ :value "Atom-Powered Robots Run Amok";
               :type "text/plain" ];
      :link [  :href <http://example.org/2003/12/13/atom03>;
               :rel iana:alternate ];
      :id <urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a>;
      :updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
      :summary [  :value "some text";
                  :type "text/plain" ].

ie, as Danny says, to apply the :title, :link, etc relations to a  
blank node
of type :Entry. By defining :id as functional we allow different  
blank node
:Entry s to have the same id, and so the contradiction we had before no
longer exists.

This is not so complicated really, it is just easy to be mislead by  
the 'id' word
and think that it must be a strong identity relation, rather than a  
weaker one.
(ie, to think that the relation is not just functional, but also  
inverse functional
symmetric and transitive)

> This seems to work pretty well for most purposes - an
> processing model, or accumulate all the versions.

yes.

> But when it comes to

For a long time I wanted to put properties on the id when I felt they
were necessary properties of the thing. The problem as James Gosling
reminded me [2] is that defining essential properties of things can
be quite tricky. And I suppose that many a document that started about
one thing ended up being about something quite different.

So I would tend initially towards conservatism, and not put any property
on the id. One could of course invent/discover such a property  
say :idabout
that would have the following rule associated with it

{ ?id :idabout ?obj .
   ?entry :id ?id . } => { ?entry :about ?obj . }

So the relation exists. It is just that it is very powerful relation,  
with
a lot of consequences that the user may not fully appreciate.  
Furthermore
it is not possible to write this relation out in atom syntax easily  
because
the id is an element content

   <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>

and so there is no way to attach elements to it.

> So in short I'd say "what Bill said", and then run away...

The link element sounds like a good way to me. You would then have
something like

[] a :Entry;
      :title [ :value "IBM Atom Robots Run Amok";
               :type "text/plain" ];
      :link [  :href <http://example.org/2003/12/13/atom03>;
               :rel iana:alternate ];
      :link [  :href <http://ibm.com>;
               :rel xxx:about ];
      :category [ a :Category;
                  :term "technology";
                  :scheme <http://example.org/categories/> ];
      :id <urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a>;
      :updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
      :summary [  :value "IBM's new atom powered robots ran amok in  
France, after having  gone through some french integration courses.  
Question is: did they integrate too well?";
                  :type "text/plain" ].

By the way, here is a nice little trick that I put in the Atom-OWL. A  
link is defined as subclass
of rdf:Statement with the extra property by asserting a link one also  
asserts the statement that it is,
ie:

    { ?link :subject ?state;
            :rel ?rel;
            :href ?obj . } => {  ?state ?rel ?obj . } .

So the above entry is equivalent to the following

[] a :Entry;
      :title [ :value "IBM Atom Robots Run Amok";
               :type "text/plain" ];
      iana:alternate <http://example.org/2003/12/13/atom03>;
      xxx:about <http://ibm.com>;
      :category [ a :Category;
                  :term "technology";
                  :scheme <http://example.org/categories/> ];
      :id <urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a>;
      :updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
      :summary [  :value "IBM's new atom powered robots ran amok in  
France, after having  gone through some french integration courses.  
Question is: did they integrate too well?";
                  :type "text/plain" ].

Which I think is neat.

Henry

> Danny.

[1] I was already working on this problem in early 2004
     https://bloged.dev.java.net/servlets/ReadMsg?list=users&msgNo=208
[2] https://bloged.dev.java.net/servlets/ReadMsg?list=users&msgNo=357
     but in fact, a lot more is understood about essential properties  
than
     the problem of the ship of theseus would let one believe. A  
lively topic
     in philosophy.

---

From: Henry Story <[email-masked]>
Date: Mon, 14 Nov 2005 14:32:33 +0100

Just thought I'd mention that there is of course nothing
in  rdf that can stop anyone giving things names. So that
the blank node could be given a name such as
<tag:example.com/versionid>

<tag:example.com/versionid> a :Entry;

And so I suppose you could treat

<urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a> as an Entry itself,
give it a title, a link, an id, etc

I am not sure this makes sense. I have formalised this doubt
in the Atom-OWL ontology by the following statement:

     :Version   a owl:Class;
          rdfs:comment "Metadata about the state of  a resource with  
given :id at an :updated time."@en;
          rdfs:subClassOf [ owl:complementOf :Id ].

Since :Entry and :Feed are subclasses of :Version, that means that
Entries or feeds cannot be ids. Perhaps that is too harsh.

Henry Story