On 2 Jul 2008, at 01:53, Mark Nottingham wrote:
On 01/07/2008, at 5:58 PM, Story Henry wrote:Nice work. I welcome the effort to find a mapping from atom to rdf. There are two problems though:(1) Rather than having an IETF document explain how to make explicit a mapping of every instance of the atom format to rdf it would be better to create an ontology for atom and specify an official GRDDL transform for it.We weren't looking for a full mapping of Atom to an ontology, but rather a lightweight way to move statements around in Atom.IMO, the problem with trying to define or use an Atom ontology has always been that most authors and extension writers don't have RDF in mind; while extracting semantics from the world around you is interesting, there also needs to be a way to shove them around with demonstrable intent, so that there isn't any ambiguity about what's happening.
If you are looking for a lack of ambiguity, then why not endorse the process of creating an official semantics for atom, such as atom-owl ? The advantage of this is that it would bring all the work from the Semantic Web side to bear on atom. A GRDDL transform would then create a standard, and unambiguous mapping from atom to RDF. This would allow discussion of extensions to make a lot more sense.
Then an extension proposals such as this one will be clear and unambiguous, because it will be clear what is being spoken about, and it will be clear what the subject of the rdf extension is about, and how the extension relates to the rest of the atom spec.
WRT using GRDDL or other out-of-band mechanisms -- the overhead of processing GRDDL is IMO not acceptable in some cases,
The GRDDL need not be the only way people extract meaning from the atom format. Specialised atom rdf parsers could I imagine come along and avoid the transform step. The GRDDL would be useful as a way to test the ontology.
and furthermore, it's again not explicit/self-describing.
? Is what you are doing self descibing? The RDF would is a lot more self describing than the atom xml... but that is another matter. ?
(2) I think the semantics of atom are wrong in the draft. It would have helped somewhat to consult on the work of the atom-owl [1] group before putting this spec together.The key problem is the value of the subject: [[ <atom:entry> <atom:id>http://example.com/a</atom:id> <atom:title>Test</atom:title> </atom:entry> and the map above as a child of at:entrymap, the following triple would be implied;<http://example.com/a> <http://purl.org/dc/elements/1.1/title> "Test" .]]By making the value of the subject be the resource identified by the id, you are going against what at least two independently built ontologies for atom consider to be the value of the subject of the entry.That is only the default; see the subject attribute.
Yes but I believe your default is very misleading. Your default breaks the best understanding one can put together of what the atom semantics is.
It also breaks a basic intuition of atom syntax which is given by the 6.4.1 section [[The element can be interpreted as a simple property (or name/value pair) of the parent element that encloses it. The pair consisting of the namespace-URI of the element and the local name of the element can be interpreted as the name of the property. The character data content of the element can be interpreted as the value of the property. If the element is empty, then the property value can be interpreted as an empty string.
]]Ie the subject of the element should be the enclosing element, not another resource inside the element.
[...]It cannot be therefore that you have correctly captured the semantics of the atom format.That is not a goal for this effort.
You are trying to entice people to use rdf in atom. So clearly the idea here is that atom has a semantics, otherwise the use of rdf in atom would be useless. The extensions you propose will create a lot of confusion in the rdf and atom camps as what everyone is speaking about. But that may well be your main aim.
Henry
Cheers, -- Mark Nottingham http://www.mnot.net/
Attachment:
smime.p7s
Description: S/MIME cryptographic signature