Subject: Re: categories and tagging

From: "Thomas Broyer" <[email-masked]>
Date: Thu, 2 Nov 2006 08:59:50 +0100

[redirecting to atom-syntax]

2006/11/1, Houghton,Andrew:
>
>   concept scheme URI: http://my.scheme.net/my-vocabulary/
>   concept URI:        http://my.concept.net/my-vocabulary/13745

<category
   scheme="http://my.scheme.net/my-vocabulary/"
   term="http://my.concept.net/my-vocabulary/13745"
   label="cats"
   />

-- 
Thomas Broyer

---

From: Henry Story <[email-masked]>
Date: Thu, 2 Nov 2006 11:34:59 +0100

> [redirecting to atom-syntax]

This is also a protocol issue, because we are asking what to do with  
the information in the atom feed. [1]

>   term="http://my.concept.net/my-vocabulary/13745"

Thomas, I don't think that this is a natural reading of "term" in the  
atom syntax list.

[[
The "term" attribute is a string that identifies the category to  
which the entry or feed belongs. Category elements MUST have a "term"  
attribute.
]]

nowhere is there mentioned a IRI there, whereas just below

[[
The "scheme" attribute is an IRI that identifies a categorization  
scheme. Category elements MAY have a "scheme" attribute.
]] [2]

The scheme attribute is defined in terms of an  IRI .

To give a bit more context to what Andrew was saying, he was arguing  
that for a mapping between the SKOS [3] vocabulary and the atom  
vocabulary. SKOS is indeed very interesting. It allows one to say  
something like

<http://my.concept.net/my-vocabulary/13745> a skos:Concept;
                  skos:inScheme <http://my.scheme.net/my-vocabulary/>;
                  skos:prefLabel "cats" .

and much more.

The question remains as to how this can be well mapped to atom.

If I take one of Tim Bray's examples

<category scheme='http://www.tbray.org/ongoing/What/'
           term='Places' />

I can translate this to the AtomOwl ontology [4]

[] a :Category;
    :scheme  <http://www.tbray.org/ongoing/What/>;
    :term "Places" .

Practically, this seems to mean that one can get all the nice info  
about Places at the url

    <http://www.tbray.org/ongoing/What/Places>

And this seems to be becoming quite a common way people are setting  
things up, and also it has some continuity with what the RSS2 folks  
were doing.

[[
<category> is an optional sub-element of <item>.

It has one optional attribute, domain, a string that identifies a  
categorization taxonomy.

The value of the element is a forward-slash-separated string that  
identifies a hierarchic location in the indicated taxonomy.  
Processors may establish conventions for the interpretation of  
categories. Two examples are provided below:
]] [5]

It follows that what we have is something that can be expressed in  
RDF by saying that the
:scheme and the :term relation form a CIFP [8], ie: together they  
uniquely identify one thing, and furthermore that the identity of the  
thing is given by the concatenation of those two strings.

This seems therefore to capture behavior that is not present in skos,  
but apart from that the two should be quite complimentary. Let us see  
how we can make them more so.

What we need perhaps is some way to make clear what the url of the  
category is.
We could do this as follows:

    1. add a new attribute to identify the category (lets call it catid)
    2. Assume that if a catid is not present, and we have scheme and  
a term attribute, that the catid is formed by the concatenation of  
the scheme+term

we could then write out

<http://my.concept.net/my-vocabulary/13745> a skos:Concept;
                  skos:inScheme <http://my.scheme.net/my-vocabulary/>;
                  skos:prefLabel "cats" .

like this

<category catid="http://my.concept.net/my-vocabulary/13745"
           scheme="http://my.scheme.net/my-vocabulary/"
           term='cats' />

Now because the "term" is mandatory in atom (and not the scheme), I  
suggest that one use the skos:prefLabel for it. I know there is a  
label too, but well, it certainly makes it easier to search for  
similar categories using the SPARQL type queries I put forward in [1].

Henry

[1] for the atom-syntax people who may not have been following this  
thread then, see
     http://blogs.sun.com/bblfish/entry/ 
folksonomies_ontologies_atom_and_the
[2] http://www.atompub.org/rfc4287.html#element.category
[3] http://www.w3.org/TR/swbp-skos-core-guide/
     (though I would suggest rewriting the rules using N3, rather  
than the Jena language)
[4] https://sommer.dev.java.net/atom/
[5] http://blogs.law.harvard.edu/tech/ 
rss#ltcategorygtSubelementOfLtitemgt
[6] http://esw.w3.org/topic/CIFP

---

From: "Thomas Broyer" <[email-masked]>
Date: Thu, 2 Nov 2006 12:19:04 +0100

> the information in the atom feed. [1]

Not sure how atom-protocol is concerned but let's keep it in
atom-protocol too...

> Thomas, I don't think that this is a natural reading of "term" in the

Andrew Houghton was talking about SKOS (which I don't know anything
about) and said:
[[
However, in SKOS you have a URI to the concept "cats", period.
You could map the domain to be the SKOS concept scheme's URI
and use the concepts label as the category content in Atom.  But
concatenating the SKOS concept scheme URI and the concept label
doesn't necessarily produce the URI to the concept.  For example,
in SKOS you might have the following:

 concept scheme URI: http://my.categories.net/
 concept URI for cats: http://my.categories.net/13745
 concept label for cats: cats
]]

My answer is a bare mapping of this description into an atom:category element.

> nowhere is there mentioned a IRI there,

IRIs are not forbidden either, and Andrew's description makes me think
the "concept URI" *is* the "term".

-- 
Thomas Broyer

---

From: Henry Story <[email-masked]>
Date: Thu, 2 Nov 2006 13:19:54 +0100

> the "concept URI" *is* the "term".

The question is: how does this help any of us? It may look like it is  
a "term", but what is a client meant to do with all this information?

So if Tim Bray uses

Then what am I meant to do with this info? Since scheme is a URL I  
can presumably go there to find something. But what?

Term is not defined to be a URI, and in the above example it is not,  
and so why should I do anything with the term below?

<category

What I am proposing is that we put forward some best practice to  
formalize a useful and RESTful way to publish this information, so  
that clients can use it. With APP we could do something like this: we  
could define for example that when entries are published and they  
contain categories that have a scheme that is accepted by the  
collection, then the entry will be found in the feed that is to be  
found either by appending scheme+term or in the catid location I  
mentioned previously.

So if Tim Bray posts an entry containing

<entry>
    ...
</entry>

and his collection manages the <http://www.tbray.org/ongoing/What/>  
scheme, as defined perhaps in the service document, (and perhaps we  
can place the list of available categories at that scheme location!)  
then his client will know that the entry will also be found in the  
<http://www.tbray.org/ongoing/What/Places> collection.

Now this would be useful for an APP publishing client, and it would  
be useful for an APP reader, because it could find some useful  
information at these various locations, and it would save us having  
to define an unending number of link relations that parallel the  
categories we have, when it is in fact clear that everybody intends  
to use scheme+term as a uri.

Henry

---

From: "Houghton,Andrew" <[email-masked]>
Date: Thu, 2 Nov 2006 08:39:07 -0500

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Thomas Broyer
> Sent: 02 November, 2006 06:19
> To: Atom-Protocol; [email-masked]; Atom-Syntax
> Subject: Re: categories and tagging
> 
> 
> 2006/11/2, Henry Story:
> >

It is both a feed issue and a protocol issue because of section 7 in
the APP draft.  The APP draft puts forth category documents where I
think there are three concerns: 1) the specification of the category
element (overlap issue), 2) how could SKOS be used as a possible
alternative to category documents, 3) scalability issues with the 
specification of category documents.

1) Because category documents reuse the Atom syntax for the category
element, this becomes an overlap issue between Atom syntax and Atom
protocol.

2) It would be an ideal convergence between Atom and SKOS to be able 
to use APP to CRUD (Create, Read, Update, Delete) SKOS concept schemes 
and concepts in an APP server.  Or for that matter, other controlled 
vocabulary XML grammars such as MARC-XML and Zthes.  Providing a 
generalized solution would plug multiple communities into APP.

3) The current specification of the category document doesn't scale
since it appears to me that this is one document in the APP server.
Lets just say you are dealing with a folksonomy of tags from say
Flickr.  There may be several thousand categories, if not several
hundred thousand.  It is doubtful that an APP server could return
such a document without HTTP timing out the request.  For controlled
vocabularies such as LCSH and MeSH there are about 300,000 and 500,000
categories respectively.  Just create a simple category document and
copy and paste a single category element 500,000 times and look at the
size of the category document.  It is just not going to be returned
by any HTTP server.

As a side note, it seems to me that APP could be used to access and 
maintain controlled vocabularies in SKOS, MARC-XML, Zthes, etc.  
Basically APP provides collections of resources.  There is a direct 
analogy in SKOS where a controlled vocabulary in SKOS contains a 
collection of skos:Concept resources.

If I understand these concepts correctly, then each skos:Concept 
could be stored within an app:collection.  The same would be true 
for each skos:ConceptScheme associated with a controlled vocabulary.
The app:collection for both skos:Concept and skos:ConceptScheme 
would comprise an app:workspace.  There could be multiple 
app:collection containing skos:Concept in an app:workspace.

To draw an analogy to the DDC (Dewey Decimal Classification, another
controlled vocabulary), each app:collection containing skos:Concept 
would represent the concepts found in a single edition of the DDC.  
Each app:workspace represents a complete controlled vocabulary.  This 
means that a single APP server, app:service, could access and maintain 
multiple controlled vocabularies.  Given this mapping, it seems to me 
that APP could replace the SKOS API and may be a better alternative to 
library centric protocols such as ADL Thesaurus protocol, OpenURL, SRU
and SRU Record Update.

The current Atom category element is just another instance of an item
in an app:collection.  Thus a category document could be used to point
to the individual concepts in an app:collection rather than embedding
the category elements inside the category document.  Using this approach
any XML grammar, Atom, MARC-XML, SKOS, Zthes, etc., could be used.

> > Thomas, I don't think that this is a natural reading of 

I agree that this is not natural since term is not specified as a URI,
per my reading of the draft, and gets back to my point that you can 
smush stuff in these attributes, but that may not be the smartest thing 
to do in the long term.

BTW, generally I prefer not to cross post, this discussion is now
spread across three lists... please confine the discussion to the
Atom protocol list so people can get the complete thread rather than
bits and pieces.

Thanks, Andy.

---

From: Henry Story <[email-masked]>
Date: Thu, 2 Nov 2006 15:50:29 +0100

On 2 Nov 2006, at 14:33, Thomas Broyer wrote:
> 2006/11/2, Henry Story:
>> Since scheme is a URL I can presumably go there to find something.  
>> But what?
>
> Some people also want to dereference XML Namespaces' URIs.

It works for the Atom namespace: http://www.w3.org/2005/Atom
You get a nice page that points you to the spec.

It works for all the AtomOwl terms, I used.

@prefix : <http://bblfish.net/work/atom-owl/2006-06-06/#> .

_:C a :Category;
      :term "13745";
      :label "cats"@en;
      :scheme <http://my.categories.net/> .

Each one of them is a URL and can be dereferenced, to find their  
meaning.

I find it odd, that a someone speaking from a group that prides  
itself on being RESTfull, does not want to get the added advantage  
that URLs provide. Especially in APP where we are concentrating so  
much on the HTTP protocol.

Yes. The information we have currently is useful. But if we get  
people to organise their web sites the way Tim Bray has, then we  
could write clients that use this information in much more  
interesting ways.  And we would not need an extension for every  
obviously good way of doing things.

Henry

---

From: "Thomas Broyer" <[email-masked]>
Date: Thu, 2 Nov 2006 14:33:05 +0100

> a "term", but what is a client meant to do with all this information?

Nothing.
A client is not meant to do anything with atom:category elements other
than for categorizing the entry or feed.

> Then what am I meant to do with this info?

You can tell the reader that the entry is in the "Places" category,
you can provide a "show other entries within this category" feature,
you can group entries by their category (in a treeview: root nodes are
the list of schemes, their child nodes are the list of terms,
presented using the provided @label; if there are different @label
used, you can default to the latest and provide a tooltip or other
contextual info such as "a.k.a. Locations, Where"), etc.

> Since scheme is a URL I can presumably go there to find something. But what?

>    term="http://my.concept.net/my-vocabulary/13745"

There's no reason you would do anything with it either.

> found either by appending scheme+term or in the catid location I

-1
But you can still do it yourself in your own implementation,
eventually with the use of an f:feature to communicate the feature to
clients.

> <http://www.tbray.org/ongoing/What/Places> collection.

I don't see how this is useful, but you might have good reasons.

> information at these various locations,

I understand the need to provide a "category URI" in some scenarios
but that should be an extension to the atom:category element or a
"mapping mechanism" communicated by a feed-level or entry-level
extension, but please no "global assumption".

> and it would save us having

Do you mean scheme+term, scheme+"/"+term or scheme+"#"+term?
or maybe scheme+"/"+term+".atom"? or scheme+"/tags/"+term?

-- 
Thomas Broyer

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 3 Nov 2006 07:10:22 +0100

* Henry Story <[email-masked]> [2006-11-02 16:55]:
> The question is: how does this help any of us? It may look like
> it is a "term", but what is a client meant to do with all this
> information?

Simple: when the scheme and term of two different entries are
identical, then you have confidence that they refer to the same
concept. When the scheme URI is absent, the term is ambiguous.

That’s what scheme and term mean, and that’s all that they mean.

If you want to use a dereferencable protocol scheme for your
category’s scheme URI, and want to run a service providing
resources at the given URI, that’s fine, and more power to you.
But nothing like that is mandated, much less is any approach for
deriving a dereferencable URI for a single term.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>