Yes, I too like PacePropertyDesign.
My way of going in that direction with minimal impact on the current standard would be as follows:
1- Agree that Atom can extended in any way one wishes with
simple name space extensibility (Tim Bray likes this [1])
2- Have a name space that belongs to the W3C
3- Have the location of that http name space contain an OWL document that
gives an OWL description of the Atom elements: head, link, etc
4- Have a very simple example that shows where one needs to place the
rdf:parseType="Resource" attributes to turn the document into RDF --
if this is needed at all.
I found the this remark by Roy T. Fielding very enlightening on the subject:
"they [RDF, XLink] are simply a means of associating crosscutting behavior
(similar to aspect-oriented programming) as an attempt to recover a
centralized meaning from namespaces' decentralized collision avoidance
strategy." [2]
As a result of this way of doing things, one would not have to introduce heavy handed
RDF syntax into Atom, nor mention it in any way, other than perhaps in passing, as an
extension strategy, or as a way to relate atom to other standards in existence (crosscutting).
All this requires is we verify one by one that all the Atom constructs could in fact be written down in a satisfactory way in OWL. This would probably in any case be a very healthy sanity check of the syntax before declaring it finished: if the syntax we define can easily and faithfully be mapped to an OWL semantics, then we will have an independent litmus test of the quality of the Atom groups' work. This would be similar to showing that two well established physics theories are in fact equivalent.
Danny, should I write the above into a Pace? Is this what you were thinking of?
Henry Story
[1] http://www.imc.org/atom-syntax/mail-archive/msg11466.html [2] http://www.imc.org/atom-syntax/mail-archive/msg11385.html
On 16 Nov 2004, at 14:39, Danny Ayers wrote:
I'm posting this in lieu of a Pace - I'll put one together post-feedback (and once I've got my current batch of day-work out of the way ;-)
The PaceEntriesAllTheWayDown thread has been looking at similarity between entities at the Entry level of granularity. This is definitely useful analysis, whether or not any of these Paces is accepted. But I think there's also a lot can gained by splitting the Atom.
There is plenty of prior art for recognising constructs in XML syntax, in the context of syndication it's provided by RDF/XML in RSS 1.0. There may not be general support for Atom as RDF/XML, but something like its grammar of structure is possible. The same kind of structural interpretation is possible without any commitment to any aspect of RDF.
Amongst other characteristics, RDF/XML identifies resources, properties and literals based on the structure of the syntax. Atom has a virtually identical set of sub-atomic particles - the constructs with URIs, properties with literal values, properties which have URIs as their value. If Atom syntax is consistent in the way it expresses these (which should be a desirable thing in itself), then the same interpretation can be applied to extensions. Things with the same Atomic Weight (or rather position in the structure) are treated in the same fashion.
I'm don't think PaceConstructAttribute is the way to go, I think it needs to be more transparent. But I reckon the rationale is good: [[ If an Atom consumer knows that an extension element follows the rules defined for a Construct that it already knows about from the Atom core specification, it may be able to perform some appropriate processing on it without knowing everything about the element. ]]
I think PacePropertyDesign is heading in the right direction, though needs some fleshing out. I would be tempted to remove the RDF references - I don't think they're needed (maybe keep as purely informative).
Cheers, Danny.
--
http://dannyayers.com
