Re: categories and tagging
[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
Re: categories and tagging
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
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... 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. 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. [[ 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, IRIs are not forbidden either, and Andrew's description makes me think the concept URI *is* the term. -- Thomas Broyer
Re: categories and tagging
On 2 Nov 2006, at 12:19, Thomas Broyer wrote: [[ 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, IRIs are not forbidden either, and Andrew's description makes me think 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 category scheme='http://www.tbray.org/ongoing/What/' term='Places' / 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 scheme=http://my.scheme.net/my-vocabulary/; term=http://my.concept.net/my-vocabulary/13745; label=cats / 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 ... category scheme='http://www.tbray.org/ongoing/What/' term='Places' / /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
html content, xml:base and xml:lang
Does xml:base and xml:lang apply to html encoded content? There is the notion of language sensitivity and content is language sensitive. So it makes sense to apply it to html content. But what about the xml:base? Henry
Re: categories and tagging
2006/11/2, Henry Story: On 2 Nov 2006, at 12:19, Thomas Broyer wrote: [[ 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, IRIs are not forbidden either, and Andrew's description makes me think 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? Nothing. A client is not meant to do anything with atom:category elements other than for categorizing the entry or feed. So if Tim Bray uses category scheme='http://www.tbray.org/ongoing/What/' term='Places' / 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? Some people also want to dereference XML Namespaces' URIs. 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 scheme=http://my.scheme.net/my-vocabulary/; term=http://my.concept.net/my-vocabulary/13745; label=cats / There's no reason you would do anything with it either. 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. -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. So if Tim Bray posts an entry containing entry ... category scheme='http://www.tbray.org/ongoing/What/' term='Places' / /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. I don't see how this is useful, but you might have good reasons. 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, 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 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. Do you mean scheme+term, scheme+/+term or scheme+#+term? or maybe scheme+/+term+.atom? or scheme+/tags/+term? -- Thomas Broyer
RE: categories and tagging
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.
Re: html content, xml:base and xml:lang
Does xml:base and xml:lang apply to html encoded content? Yes, definitely. -- GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist! NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl
Re: html content, xml:base and xml:lang
+1 A. Pagaltzis wrote: Does xml:base and xml:lang apply to html encoded content? Yes, definitely.
How to do RESTful SEARCH (was Re: Adding POST capability to atom:link)
On Oct 26, 2006, at 1:02 PM, Jan Algermissen wrote:If you aim to provide a REST interface, do not mimick a query interface (at least not a complex one). Think of your 'asset space' in terms of pre-defined, useful collections that you expose as resources (feeds) and provide light weight query interfaces to them that fit with GET requests.Think in terms of browsing and drilling-down; REST interfaces guide the client into the content instead of assuming the knowledge to constructa query does reside in the client.This is an interesting assertion about REST. I don't yet agree with it as stated though I might after further discussion and elaboration. To provide a possible counter-example, I always found the HTTP SEARCH proposal http://www.greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html to be RESTful because - The results of a search are returned as a set of resource identifiers - It doesn't necessarily break for dynamic resources as long as the server can handle that - It doesn't break the layering of representations, or use of connectors, or caching of resources - It's general -- can be used for WebDAV resources but also for any HTTP server, CalDAV resources or probably (with some thought) Atom resourcesA server that instead provides light-weight query interfaces as you describe, or guides the client into the content, does not work with a client that doesn't do HTML (a CalDAV, WebDAV or possibly Atom authoring client); correct?Lisa
Re: How to do RESTful SEARCH (was Re: Adding POST capability to atom:link)
A server that instead provides light-weight query interfaces as you describe, or guides the client into the content, does not work with a client that doesn't do HTML (a CalDAV, WebDAV or possibly Atom authoring client); correct?My understanding (for what it is worth) is that REST *requires* hypermedia. Your choice of hypermedia then constrains your problem domain. Once you select a domain (HTML, Atom, whatever), then to be RESTful it is important give clients within that domain a way to discover the appropriate syntax using hypermedia.It sounds like you're asking about the protocol independent of how it is presented on the Web. In that case, I think it is fine to say that, e.g., SEARCH *can* be used RESTfully, but I don't think it is *necessarily* RESTful unless we know the rest of the application.My $.02.-enpOn Nov 2, 2006, at 12:06 PM, Lisa Dusseault wrote:On Oct 26, 2006, at 1:02 PM, Jan Algermissen wrote:If you aim to provide a REST interface, do not mimick a query interface (at least not a complex one). Think of your 'asset space' in terms of pre-defined, useful collections that you expose as resources (feeds) and provide light weight query interfaces to them that fit with GET requests.Think in terms of browsing and drilling-down; REST interfaces guide the client into the content instead of assuming the knowledge to constructa query does reside in the client.This is an interesting assertion about REST. I don't yet agree with it as stated though I might after further discussion and elaboration. To provide a possible counter-example, I always found the HTTP SEARCH proposal http://www.greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html to be RESTful because - The results of a search are returned as a set of resource identifiers - It doesn't necessarily break for dynamic resources as long as the server can handle that - It doesn't break the layering of representations, or use of connectors, or caching of resources - It's general -- can be used for WebDAV resources but also for any HTTP server, CalDAV resources or probably (with some thought) Atom resourcesA server that instead provides light-weight query interfaces as you describe, or guides the client into the content, does not work with a client that doesn't do HTML (a CalDAV, WebDAV or possibly Atom authoring client); correct?Lisa
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On Oct 18, 2006, at 1:04 AM, Sylvain Hellegouarch wrote: My assumption: a client cannot create a media resource without also creating a media link entry. When I POST a media resource to a collection, a media link entry is *always* created. Same here. Lisa what do you mean by creating a media resource manually? If you do not use an APP service to create a media resource then it does not fall into APP to tell how this resource will be accessible. To me it's like it's not even part of the collection. I was assuming the opposite of what James assumed, so under my personal world-view "create a media resource manually" meant to create a media resource without also creating the media link entry at the same time.To illustrate my disconnect more, I'll borrow James Snell's concrete example and show what I thought would obtain instead:On 2006/10/17, at 4:40 PM, James M Snell wrote:My assumption: The relationship between a media link entry and a mediaresource is always 1-to-1. If I want an entry to point to multiplemedia resources, then I would create one media link entry for each mediaresource, then create a separate entry that points to each of theindividually created media resources.e.g., entry1 -- pic1 entry2 -- pic2 entry3 -- pic3 entry4 -- pic1 -- pic2 -- pic3Entries 1, 2 and 3 will always point to their respective media resources(using atom:content/@src).My idea was that if I want to create an entry to point to multiple media resources, I might first create the entry as I edit text about my fabulous trip to Lisbon, entries: entry1Then when I add pictures to the entry I'm editing, my client would "manually" create the media resources by posting to the media collection, such that no media link entry was created for each of them. At the same time, the client would probably PUT to the entry each time to update and add the link to the pictures. entries: entry1 -- pic1 -- pic2 -- pic3 media resources: pic1 pic2 pic3Of course this can be done in fewer steps if the client is implemented to do editing offline and only upload the whole kaboodle when I'm done. In that scenario, entry2 with images pic4 and pic5 would be created with a minimum of POSTs and no PUTs, step 1 is POSTing the images: entries: entry1 -- pic1, pic2, pic3 media resources: pic1, pic2, pic3 NEW pic4 NEW pic5Step 2 is POSTing the entry with the links obtained from creating the images: entries: entry1 -- pic1, pic2, pic3 NEW entry2 -- pic4, pic5 media resources: pic1, pic2, pic3 pic4 pic5I may be wrong about this model and James is likely to be right as having followed the discussion more carefully, but I don't believe the draft clearly leads the reader to James' model. Lisa
Re: How to do RESTful SEARCH (was Re: Adding POST capability to atom:link)
Lisa, first, I think I misread Mark's point when I quoted his blog entry: The Web doesn’t do generic query http://www.markbaker.ca/blog/2006/08/09/sparql-useful-but-not-a-game- changer/ He does talk about hiding the actual query by merely passing in parameters; he does not talk about dividing the query space into subsets. Sorry about that. On Nov 2, 2006, at 9:06 PM, Lisa Dusseault wrote: On Oct 26, 2006, at 1:02 PM, Jan Algermissen wrote: If you aim to provide a REST interface, do not mimick a query interface (at least not a complex one). Think of your 'asset space' in terms of pre-defined, useful collections that you expose as resources (feeds) and provide light weight query interfaces to them that fit with GET requests. Think in terms of browsing and drilling-down; REST interfaces guide the client into the content instead of assuming the knowledge to construct a query does reside in the client. This is an interesting assertion about REST. I don't yet agree with it as stated though I might after further discussion and elaboration. To provide a possible counter-example, I always found the HTTP SEARCH proposal http://www.greenbytes.de/tech/webdav/ draft-reschke-webdav-search-latest.html to be RESTful I did not mean to say that using very many parameters was breaking REST, I only meant to say that dividing the space is propably decreasing the level of coupling as the client needs to know fewer parameters. Of course it needs to OTH understand the meaning of the subsets but it might already do that anyway. Hard to evaluate in the absence of the domain context. Maybe think about a resource representing all items of 'last week' as opposed to providing start-date and end-date parameters to narrow down the result set to 'last week'. because - The results of a search are returned as a set of resource identifiers - It doesn't necessarily break for dynamic resources as long as the server can handle that - It doesn't break the layering of representations, or use of connectors, or caching of resources - It's general -- can be used for WebDAV resources but also for any HTTP server, CalDAV resources or probably (with some thought) Atom resources A server that instead provides light-weight query interfaces as you describe, or guides the client into the content, does not work with a client that doesn't do HTML (a CalDAV, WebDAV or possibly Atom authoring client); correct? I wouldn't say so; the question of MIME type is orthogonal to the question of parameters vs. collections. Or am I misreading you? Jan Lisa
Re: categories and tagging
* Henry Story [EMAIL PROTECTED] [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/
