Subject: Validation of multiple atom:category elements, role of schemas in Atom validation.

From: "Ian Mayo" <[email-masked]>
Date: Mon, 22 Sep 2008 14:24:01 +0100

Hi all,
I'm aspiring to use atom:category elements in a number of schemes to
define a series of attributes of my data items, as espoused at:
http://www.majordojo.com/2006/05/overloading-atomcategory.php

I'm relatively comfortable with the representation of privacy and
security via scheme, term, and label, but am stumbling at the
challenge of representing these concepts in a schema.  It appears that
XSD isn't able to define a set of valid terms for one scheme, with
another set that are only valid in association with another scheme.
Having had a look around at various specifications based on Atom
(including the Google data ones), they don't go as far as defining a
computer-readable schema, they stop at the human-readable schema (as
for the Atom spec).

Would somebody mind giving me an idea of why it appears to have become
acceptable to define these data-exchange mechanisms just using a
human-readable format that can't be enforced by computer?  For a
system involving the exchange of data using an Atom-derived format,
the lack of a computer-enforceable schema seems a real handicap.

I welcome advice in this matter.

cheers,
Ian

---

From: "James Abley" <[email-masked]>
Date: Mon, 22 Sep 2008 16:01:41 +0100

> I welcome advice in this matter.

The spec comes with a RNG schema [1], which AFAIK is
computer-readable? For instance, Jing can be used [2].

Cheers,

James

[1] http://tools.ietf.org/html/rfc4287#appendix-B
[2] http://www.thaiopensource.com/relaxng/jing.html

---

From: "Brian Smith" <[email-masked]>
Date: Mon, 22 Sep 2008 10:11:59 -0500

Ian Mayo wrote:
> I'm aspiring to use atom:category elements in a number of 
> schemes to define a series of attributes of my data items, as 
> espoused at:
> I'm relatively comfortable with the representation of privacy 
> and security via scheme, term, and label, but am stumbling at 
> the challenge of representing these concepts in a schema.  It 
> appears that XSD isn't able to define a set of valid terms 
> for one scheme, with another set that are only valid in 
> association with another scheme.
>
> Having had a look around at various specifications based on 
> Atom (including the Google data ones), they don't go as far 
> as defining a computer-readable schema, they stop at the 
> human-readable schema (as for the Atom spec).
> 
> Would somebody mind giving me an idea of why it appears to 
> have become acceptable to define these data-exchange 
> mechanisms just using a human-readable format that can't be 
> enforced by computer?  For a system involving the exchange of 
> data using an Atom-derived format, the lack of a 
> computer-enforceable schema seems a real handicap.

That is one reason why I recommend using atom:category only for user
categorization, and extension elements for everything else. If you don't
want users to add, remove, and change the categories then using
atom:category will create problems because (1) there is no standard way of
communicating what schemes/categories should be exposed to the end-user for
editing, (2) there is no (standard) way to communicate your categorization
restrictions (schema) to a client that allows the user to change the
categorization, (3) even if there was such a standard schema mechanism, it
is very difficult to convert that machine-readable schema into a user
interface that makes sense for the user.

That blog post linked to James's explanation of how his software uses
atom:category, but it seems to me that his software could have used
extension elements instead of categories for the application-specific
metadata without any trouble.

- Brian

---

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Mon, 22 Sep 2008 17:20:28 +0200 (CEST)

>> computer-enforceable schema seems a real handicap.

I wonder if RelaxNG and schematron wouldn't be more flexible in that
context to describe your schema.

> interface that makes sense for the user.

If you're willing to create your own extension, why not simply use RDF (or
one of its relatives) as foreign content? What is the added value of an
extension in such case?

- Sylvain

---

From: "Brian Smith" <[email-masked]>
Date: Mon, 22 Sep 2008 11:08:01 -0500

Sylvain Hellegouarch wrote:
> If you're willing to create your own extension, why not 
> simply use RDF (or one of its relatives) as foreign content? 
> What is the added value of an extension in such case?

Please give an example of what you mean? For somebody that doesn't use RDF
tools, doing anything with RDF doesn't seem simple at all. 

    <entry xmlns='http://www.w3.org/2005/Atom'>
      ...
      <extension xmlns='http://xmlns.example.org'/>
    </entry>

Since this is a simple extension element (by syntax), it must be metadata
about the entry (by definition). Any Atom+RDF tool should be able to create
RDF triples out of that without issues.

- Brian

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Mon, 22 Sep 2008 18:23:18 +0200

> RDF triples out of that without issues.
Ian seems to use atom:category as a simple ontology format (which I 
personally favor too). Creating an extension probably means either 
re-using an existing format that is appropriate for OWL or define your 
own. Now I don't immediatly understand why an extension would be better 
than straight RDF (or a relative). In other word, why don't you think 
embedding RDF as foreign content is worse than an extension in this 
particular context?

- Sylvain

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Mon, 22 Sep 2008 19:29:13 +0200

> RDF triples out of that without issues.
Out of what? You have defined an element with a different namespace but 
how does it convey any of the information an atom:category conveys? I'd 
be happy to try to give an example in comparison to yours but I don't 
understand how you provide the same amount of information here.

Or perhaps your extension here means that the entire set of category 
elements of that entry will abide rules described by this extension. Is 
that correct? If so, could you use several distinc extensions?

Maybe I'm misunderstanding your entire point, in that case, my apology.
- Sylvain

---

From: "Brian Smith" <[email-masked]>
Date: Mon, 22 Sep 2008 12:57:22 -0500

Sylvain Hellegouarch wrote:
> Brian Smith a écrit :
> > Since this is a simple extension element (by syntax), it must be 
> > metadata about the entry (by definition). Any Atom+RDF tool 
> > should be able to create RDF triples out of that without issues.

> Out of what? You have defined an element with a different 
> namespace but how does it convey any of the information an 
> atom:category conveys? I'd be happy to try to give an example 
> in comparison to yours but I don't understand how you provide 
> the same amount of information here.

What information does atom:category convey? What is a category, in Atom,
really? It is whatever it is defined to be. Simple extension elements are
the same way. What is the difference in meaning between these two elements?:

   <atom:category scheme='http://scheme.example.org/' term='fact'/>
   <fact xmlns='http://scheme.example.org/'/>

You can't tell what either of them means without knowing something about
"http://scheme.example.org" and its "fact" component. They might even mean
exactly the same thing.

> Maybe I'm misunderstanding your entire point, in that case, my apology.

My point is that atom:category is underspecified, so it is better to just
let end-users do whatever they want with it, and use something else for
things that are supposed to have precise, computer-actionable semantics.

- Brian

---

From: Aristotle Pagaltzis <[email-masked]>
Date: Tue, 23 Sep 2008 02:46:49 +0200

* Brian Smith <[email-masked]> [2008-09-22 17:25]:
> it seems to me that his software could have used extension
> elements instead of categories for the application-specific

Possible trouble would be that categories are very nearly certain
to roundtrip correctly whereas extension elements may possibly
get dropped on the floor in transit. (I am not proposing that
this is is a very strong argument.)

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

---

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Tue, 23 Sep 2008 11:21:19 +0200 (CEST)

> things that are supposed to have precise, computer-actionable semantics.

But you can't unless, as you suggested, you know the meaning of said
namespace. So in any case, consumers that automate handling of your entry
will need to be programmed in order to either understand that namespace or
leave it alone.

I can appreciate your point of not stuffing everything into an element
that can mean anything and probably that could hurt the end users who
consumes entries via a regular feed reader. That's fair in that particular
context. But then again, without any further specification, you jump from
underspecified to overly restrictive behavior of the atom:category
element. I don't really find that attractive as a generalized best
practice. You may have services that will not be for public usage and I
find using atom:category in that context entirely natural and safe.

In regards to using RDF, now that I understand your point I can see why it
didn't answer your initial statement.

- Sylvain
-- 
Sylvain Hellegouarch
http://www.defuze.org