On 2 Nov 2006, at 08:59, Thomas Broyer wrote:
[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]
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, 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
--
Thomas Broyer
[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
