Sorry Bill, only just noticed this - overactive Gmail filters... On 10/22/05, Bill de hÓra <[EMAIL PROTECTED]> wrote: > James M Snell wrote: > > Bill de hÓra wrote: > > > >>> For instance, suppose that I want to > >>> indicate that an entry is about http://www.ibm.com and file that in a > >>> category called technology? The categorization of the entry is > >>> different than the subject of the entry.. tho both are definitely > >>> related. > >>> > >> > >> > >> There are two distinct forms of discourse going on here > >> > >> - This entry is talking about some subject area or entity or resource. > >> It says something about something else. Being able to do this pretty > >> much why RDF was invented. > >> > >> - This entry is classifiable under some subject area or topic or class. > >> It has something has sense of belonging or association to something > >> else. Being able to do this is pretty much why Topic Maps were invented. > >> > >> Please, please, please, do not conflate these. > >> > >> > >> > > Oh absolutely, I'm not trying to conflate 'em. I want to find a > > solution to the first case ("this entry is talking about some subject > > area") that preferably does not involve invention or abuse of existing > > formats/tags. I'm more than aware that RDF does this already but I not > > sure how that fact helps us in Atom (which is not RDF). > > [RDF and TM were exemplary; cc'd to Henry/Danny] > > Ah ok; I had read the proposal initially as subject classification > (dc:subject had me thinking that way). > > If you're looking for a way to say this is entry is saying stuff about > something over there, then dc:subject and atom:category aren't a good > fit as they're more or less pointing the wrong way. rdf:about is the > closest analog in semweb land (plus it takes urls), but it's the wrong > thing here (I'll get to this). > > You could do any of the following: > > - define an atom:about tag or attribute that takes a URL. > - use a @rel=about on a link tag > > You can't use an rdf:about on the atom:entry element for this and that's > to do with entry metadata associations. What we want to say is that the > entry to talking about something else. With rdf:about the entry > *metadata* will become bound to the something else and not the entry > (which is messed up). The only sensible way I see is to work in terms of > the entry URI and the URI you're pointing at: 'entryURI isabout > someOtherURI' and define a new term for this purpose. Anyone that wants > to model this formally has enough information in the entry markup to > consistently generate the correct RDF statements out of band. > > [I'm not suggesting RDF stuff for this - it's just very useful for > teasing out issues]
(I've cc'ed the atom-owl list, this is certainly in scope over there). I think Bill's right about the direction being the issue, and has probably got the right answer with adding another property to the entryURI, but there's a fair bit of devil in the detail. There's a slight mismatch between Atom's id and resource identification in the RDF sense (Henry, you've looked at this hardest - please correct me if I'm wrong). Entries can appear with different values but the same id, e.g. [[ If multiple atom:entry elements with the same atom:id value appear in an Atom Feed Document, they represent the same entry. Their atom: updated timestamps SHOULD be different. ]] 4.1.1 So if atom:id is treated as the entry resource URI then in a literal RDF interpretation of the Atom spec you either end up with information loss, older versions of the entry ceasing to exist (which doesn't really work with either Atom or the RDF model) or contradictions, e.g. more than one content value for an entry when the properties of the resources are lined up together. The way we got around this in Atom/OWL is to make the entry itself a blank node, with atom:id being a property of it. The unique identification of the entry node being provided by the combination of the id, updated (and some other stuff - multiple language support is a complication). This seems to work pretty well for most purposes - an application could either take the "forget older entry versions" processing model, or accumulate all the versions. But when it comes to saying what the entry in about, I think you'd almost certainly expect all *versions* of an entry to be about the same thing, so the subject of the statement would be the id URI. This is easy enough in RDF (the id is a resource), but it's not obvious how this migght be expressed in Atom syntax. So in short I'd say "what Bill said", and then run away... Cheers, Danny. -- http://dannyayers.com
