Subject: Quark, Strangeness and Charm

From: Danny Ayers <[email-masked]>
Date: Tue, 16 Nov 2004 14:39:28 +0100

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

---

From: Henry Story <[email-masked]>
Date: Tue, 16 Nov 2004 15:32:46 +0100

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

---

From: Martin Duerst <[email-masked]>
Date: Wed, 17 Nov 2004 07:38:21 +0900

>	if this is needed at all.

In the simpler cases (and I think this may apply to Atom), there
are even well-known formal ways to describe this. It's just default
attributes, so any DTD can do it. There would be a standard DTD
for Atom (without these attributes), and an RDF-oriented (with
these attributes). With that RDF-enhanced DTD, it might go straight
into an RDF parser.

Regards,    Martin.

---

From: Danny Ayers <[email-masked]>
Date: Wed, 17 Nov 2004 12:21:32 +0100

> these attributes). With that RDF-enhanced DTD, it might go straight

If I remember correctly, the use of DTDs in this way have passed
through the list before (pre-IETF). I think the idea was discounted at
the time for one or two practical reasons (sorry, I forget why, and
Googling didn't help), but given the present circumstances it may well
be worth revisiting. If a DTD could be used to provide a transparent
overlay in this way without breaking anything else, that'd be great.

Henry's approach of having an implicit mapping to RDF that can be made
explicit through the insertion of one or two other-namespace
attributes really does sound a low-cost, potentially uncontroversial
way of making an RDF interpretation available. I think this may also
offer a good reference for structural interpretation of extension
elements too (as in Quark, Strangeness and Charm).

Cheers,
Danny.     

-- 

http://dannyayers.com

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 18 Nov 2004 09:30:30 +0100

> overlay in this way without breaking anything else, that'd be great.

Couldn't any document typing or schema language (e.g. XSD) do this? I too  
remember DTD's were abandoned, and it was probably for good reasons, but I  
don't remember what they were, either. But that's okay, because I don't  
like DTD's anyway. :-)

> elements too (as in Quark, Strangeness and Charm).

Examples?

-- 
Asbjørn Ulsberg     -=|=-    http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»