> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Broyer > Sent: 02 November, 2006 06:19 > To: Atom-Protocol; [EMAIL PROTECTED]; Atom-Syntax > Subject: Re: categories and tagging > > > 2006/11/2, Henry Story: > > > > 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] > > Not sure how atom-protocol is concerned but let's keep it in > atom-protocol too...
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. > > > 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. 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.
