Re: AtomOWL & AtomAsRDF
Henry Story wrote: Ok. I take that as being that your kind of for it :-) More than that; I think an ability to a) evaluate extensions in a uniform manner, b) determine if they are being applied appropriately, c) have the evaluation results output as more metadata, is immensely valuable. I think when you appreciate that value, the point of technologies like RDF become more apparent. But in my mind this work falls into innovation space rather than standards space. cheers Bill
Re: AtomOWL & AtomAsRDF
On 18 Jan 2005, at 01:26, Danny Ayers wrote: On Mon, 17 Jan 2005 23:38:50 +0100, Henry Story <[EMAIL PROTECTED]> wrote: Take for example the following extension proposed recently tag://sometag 10.1 57.3 ... this implies the following rdf graph _e -entry-> _E |-id--> |-geo:x->"10.1" |-geo:y->"57.3" which presumably would mean that _E had to be both an Entry and a geographical location, ...or an entry *with* a geographic location (or something completely different). Yes. It all depends of course on how the geo ontology has defined its predicates. My point was to show a little how this gives a framework for extension writers to think about their extensions. It constrains extension writers the way logic constrains us in what we say, and that has never stopped people from speaking gibberish. It would probably help to work with a concrete example. That would show what effect each decision had, and give us a good way to discuss whether that was what the author intended. Perhaps we could start a thread taking a reasonable extension idea, and use that to discuss how they would be best off writing their extension in Atom+OWL. Henry
Re: AtomOWL & AtomAsRDF
On 18 Jan 2005, at 02:18, Bill de hÓra wrote: Henry Story wrote: this implies the following rdf graph _e -entry-> _E |-id--> |-geo:x->"10.1" |-geo:y->"57.3" [On a technical point, I would disagree the graph is implied. As I said earlier, this kind of assumption concerns me.] It will be when the gap between atom as it currently is and where it would have to be for it to be correctly seen as RDF is closed. As you see there is not that much to closing the gap. And there are many ways of doing this, which need to be looked at, and evaluated for those that form the best compromise solution. If you look at the AtomOWL spec, you will see that among other things it is simply a specification of what types of objects a relation can take as subject and as Object. This is what I'm getting from the proposal - if range and domain for extensions are determined, a semantically 'consistent' (I won't say 'meaningful') extensibility framework for applying them to Atom structures can be established. So since we have evaluation rules above the level of data structures, we can determine if any extra metadata satisfies the constraints. Two things come to mind if that is a fair summary. First, I don't see how it can be done generally without RDF backed ontological modeling to begin with - which would be AtomIsRDF. Correct me if I'm wrong, but I think for this to work I would need to know what the essence of Atom domain constructs are before I can determine whether a new property can be correctly be applied to one. Yes, if I have understood you correctly. That is why I have AtomOWL which gives you the essence of the Atom domain constructs. For example it specifies that atom:id is functional, which says that two Entries are different if they have different ids. I have tried to express all the number constraints that the spec defines too, such as a Feed requiring one Header and no more. I call this AtomAsRDF rather than AtomIsRDF because the point is that we are trying to make this completely invisible for anyone who does not want to know, or has not yet had time to learn these constructs. Second, I've said before, my position is that Atom doesn't require extensibility. Tim for one, has taken umbrage with my use of the word 'extensible', but what you're proposing isn't far away from what I would mean by it - extensions and their relationships are processed through an evaluator. I just happen to think we don't need to spec this yet*. I think that the spec does speak about extensibility and a model for atom. With AtomAsRDF and AtomOWL I provide both. Even if we did not need this yet, it certainly won't harm to track the differences, and the obvious problems that some decisions entail. For example modeling the Person construct it is obvious that the e-mail address should be "inverse functional" and not functional as we have it now. Ie if we have 2 Person objects (be they in an author or contributor tag) anywhere in the xml with the same email address, we should be able to conclude that these are in fact the same person. The model sometimes also can help spot gaps in the spec, which cannot be a bad thing. It is better these gaps be found now than later when it will be difficult to change anything. So, I'm not -1 on this, but I do think it's out of scope. Ok. I take that as being that your kind of for it :-) By the way I think that there are many people out there who don't want to hear about RDF in so far as it is plastered all over their xml in big bold letters. They don't want rdf:li here and rdf:resource there. They don't want xml that is not in a nice tree shape, but just a set of statements about the relationship between things. They want to use XPath and other well tested tools. Apart from that they probably don't have anything really against RDF (apart from that one has the suspicion it could have been better done, but then that is true with all technologies - one need look no further than default namespaces in xml). So I think these people have nothing to worry about the current proposal. They have everything they want. And they have something extra: in their spare time they can learn about that weird thing called rdf. This would be seamless integration. And I think is the foundation of a good long lasting compromise. cheers Bill * I would include trying to make explicit whatever the child_of() evaluation rules might be for XML containership here.
Re: AtomOWL & AtomAsRDF
Henry Story wrote: this implies the following rdf graph _e -entry-> _E |-id--> |-geo:x->"10.1" |-geo:y->"57.3" [On a technical point, I would disagree the graph is implied. As I said earlier, this kind of assumption concerns me.] If you look at the AtomOWL spec, you will see that among other things it is simply a specification of what types of objects a relation can take as subject and as Object. This is what I'm getting from the proposal - if range and domain for extensions are determined, a semantically 'consistent' (I won't say 'meaningful') extensibility framework for applying them to Atom structures can be established. So since we have evaluation rules above the level of data structures, we can determine if any extra metadata satisfies the constraints. Two things come to mind if that is a fair summary. First, I don't see how it can be done generally without RDF backed ontological modeling to begin with - which would be AtomIsRDF. Correct me if I'm wrong, but I think for this to work I would need to know what the essence of Atom domain constructs are before I can determine whether a new property can be correctly be applied to one. Second, I've said before, my position is that Atom doesn't require extensibility. Tim for one, has taken umbrage with my use of the word 'extensible', but what you're proposing isn't far away from what I would mean by it - extensions and their relationships are processed through an evaluator. I just happen to think we don't need to spec this yet*. So, I'm not -1 on this, but I do think it's out of scope. cheers Bill * I would include trying to make explicit whatever the child_of() evaluation rules might be for XML containership here.
Re: AtomOWL & AtomAsRDF
On Mon, 17 Jan 2005 23:38:50 +0100, Henry Story <[EMAIL PROTECTED]> wrote: > Take for example the following extension proposed recently > > >tag://sometag >10.1 >57.3 >... > > > this implies the following rdf graph > > _e -entry-> _E > |-id--> > |-geo:x->"10.1" > |-geo:y->"57.3" > > which presumably would mean that _E had to be both > an Entry and a geographical location, ...or an entry *with* a geographic location (or something completely different). which is a very > unintuitive concept, and very likely *not* what the > extension author intended. It would for example meant > that this object would be a different object if it had > a different id. > > What he probably intended was either > > - That the author was at some particular location, in which case he > should > probably have added attributes to the author object, through some foaf > ontology predicate. > > - Or that some event the Entry is about was at some particular > location. In which > case this should have gone into the space by using > an event > ontology. Maybe, but there's always the trade-off between accuracy of modelling and difficulty of handling the stuff. There's really nothing to stop the resource identified in being a geological event with a geographic location as well as something with a representation in the content of an entry in an Atom feed. The indirection can be reduced with the data expressing what the entry is, rather than what it is about. This example probably works better than most in human terms, as the entry could be an entry in an event log, though you could end up with the author of the feed entry being the creator of the earthquake... Cheers, Danny. -- http://dannyayers.com
Re: AtomOWL & AtomAsRDF
The goal is not at all the wider adoption of RDF. The way I am proposing atom be seen as RDF will hopefully be completely invisible to anyone who does not know that it is. The point of being able to - if you will allow me the C,C++ idiom - cast an atom document to RDF will be to make it clear how to structure extensions. RDF alone does not do this, but RDF and the AtomOWL ontology does. It does this in a way that all Object Oriented programming languages do this: by specifying how concepts hook together. Take for example the following extension proposed recently tag://sometag 10.1 57.3 ... this implies the following rdf graph _e -entry-> _E |-id--> |-geo:x->"10.1" |-geo:y->"57.3" which presumably would mean that _E had to be both an Entry and a geographical location, which is a very unintuitive concept, and very likely *not* what the extension author intended. It would for example meant that this object would be a different object if it had a different id. What he probably intended was either - That the author was at some particular location, in which case he should probably have added attributes to the author object, through some foaf ontology predicate. - Or that some event the Entry is about was at some particular location. In which case this should have gone into the space by using an event ontology. Eg: _e --content-> _event --is-a-> |---location--->_loc --is-a-> |--geo:x-->"10.1" |--geo:y-->"57.3" The Object of the content predicate can accept anything (in java this would be a method that returned an Object), so it can accept among other things an xxx:Event. If you look at the AtomOWL spec, you will see that among other things it is simply a specification of what types of objects a relation can take as subject and as Object. Now we could define other mappings from xml to RDF. I have put forward some proposals that I think could bring this much closer to the intuitions of Tim Bray as expressed on this list. But we just don't have time. And since Atom is anyways so close to being RDF, I think the easiest route is simply to use the work done by others. I think the price is pretty minimal. And we will end up with a format that is extensible and even better defined than RSS1.0 Henry Story On 17 Jan 2005, at 22:43, Bill de hÓra wrote: Incidently the name AtomIsRDF isn't as problematic as the latent assumption - that Atom is some of kind of degenerate or special case of RDF. My opinion is that's a losing strategy if the goal is wider adoption of RDF.
