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--><tag://sometag> |-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.
