Comments on Draft APML
6 views
Skip to first unread message
Renato Iannella
Sep 18, 2008, 11:10:45 PM9/18/08
to APML.Public.General
Hi all - sorry if these comments have been already discussed, but I
have just joined the group as we are embarking on a new project
looking at Social Networks Interoperability.
Some comments/feedback/questions on the latest draft [1]:
General:
1 - Are there any Use Cases and/or Scenarios that are driving the
design decisions for APML?
Section 4.0:
2 - Why the use of the <Head><Title><Body> structure - seems very HTML-
ish - and not really required for an XML structure?
3 - In the Document Head <Target> element, did you consider just using
a URI instead of the additional attribute type for "email",
"emailhash" and "url". That is, the URI can tell you the type:
mailto:f...@email.com
md5:34fwef3f3434
http://ex.com
Section 5.2 and 5.3:
4 - Why is there such an "explicit" separation of Implicit and
Explicit data? What if the data originated as implicit (auto-
generated) then updated by a human?
Section 5.4:
5 - Why use the term "Concept" and not "Interest" (as Concept seems
more abstract and we want to express real areas of interest - which is
the core of APML spec)?
6 - Why use the attribute "key" as this implies uniqueness, which the
value may not be? Perhaps "term" or "topic" instead?
7 - Why use the attribute "value" as it really is "relevance" (the
former implies the value for the element)?
8 - Why is "rdf:about" used here and "Link" used in People for the
same purpose?
(Also, did you want to introduce a new namespace?)
Section 5.5:
9 - I wanted clarify the example on this section. It seems to say that
you are not interested in the Source (-0.5) but are somewhat
interested in the Author (+0.2)?
10 - What not reuse the People structure for Author?
Section 5.7:
11 - You may need to be explicit on the default coordinate reference
system when using long/lats. Usually WGS84, but there are others.
Information Model:
12 - Is there an "information model" - this makes it clearer to
understand the spec and easier if (and when) you need to map to other
models (eg RDF).
I was thinking that the core model would describe Interest in a
particular Object. The Interest would have a Relevance and Link to
additional info, and an Origin from which it was generated (if
automatic) and hence implicit (otherwise explicit). Each Object would
be one of Topic, Person, Source, or Location (which can be extended in
the future...)
So, a high-level pseudo-XML would look like:
<interest>
<object> ... </object>
<relevance> 0.2 </relevance>
<link> http://more.here </link>
<origin>http://my-generator.com</origin>
</interest>
and <object> could contain anyone of these four:
<topic> Australian Wine </topic>
<source> <feed>http://ex.com/atom</feed> <imt>app/xml+atm</imt></
source>
<person> Marilyn Monroe </person>
<location> <place> Gold Coast</place><long> 23.2 </long><lat> 22.33 </
lat></location>
If you wanted to add a Person to the Source, we can link the
<interest> elements with IDs:
<interest id="mdrudge">....
<interest>
<source> <feed>http://ex.com/atom</feed> <person idref="#mdrudge">
</source>
Thanks for the opportunity to post these questions and feedback....
Cheers...
Dr Renato Iannella
Principal Scientist, National ICT Australia (NICTA)
Level 5, Axon Building #47, Staff House Rd, St Lucia, QLD, 4072,
AUSTRALIA
[t] +61 7 3300 8520 [f] +61 7 3300 4820 [m] +61 4 1313 2206
[e] ren...@nicta.com.au [w] http://nicta.com.au
[im] skype:riannella aim:renatoi2003
[1] <http://groups.google.com/group/apml-public/web/apml-1-0-draft-1>
have just joined the group as we are embarking on a new project
looking at Social Networks Interoperability.
Some comments/feedback/questions on the latest draft [1]:
General:
1 - Are there any Use Cases and/or Scenarios that are driving the
design decisions for APML?
Section 4.0:
2 - Why the use of the <Head><Title><Body> structure - seems very HTML-
ish - and not really required for an XML structure?
3 - In the Document Head <Target> element, did you consider just using
a URI instead of the additional attribute type for "email",
"emailhash" and "url". That is, the URI can tell you the type:
mailto:f...@email.com
md5:34fwef3f3434
http://ex.com
Section 5.2 and 5.3:
4 - Why is there such an "explicit" separation of Implicit and
Explicit data? What if the data originated as implicit (auto-
generated) then updated by a human?
Section 5.4:
5 - Why use the term "Concept" and not "Interest" (as Concept seems
more abstract and we want to express real areas of interest - which is
the core of APML spec)?
6 - Why use the attribute "key" as this implies uniqueness, which the
value may not be? Perhaps "term" or "topic" instead?
7 - Why use the attribute "value" as it really is "relevance" (the
former implies the value for the element)?
8 - Why is "rdf:about" used here and "Link" used in People for the
same purpose?
(Also, did you want to introduce a new namespace?)
Section 5.5:
9 - I wanted clarify the example on this section. It seems to say that
you are not interested in the Source (-0.5) but are somewhat
interested in the Author (+0.2)?
10 - What not reuse the People structure for Author?
Section 5.7:
11 - You may need to be explicit on the default coordinate reference
system when using long/lats. Usually WGS84, but there are others.
Information Model:
12 - Is there an "information model" - this makes it clearer to
understand the spec and easier if (and when) you need to map to other
models (eg RDF).
I was thinking that the core model would describe Interest in a
particular Object. The Interest would have a Relevance and Link to
additional info, and an Origin from which it was generated (if
automatic) and hence implicit (otherwise explicit). Each Object would
be one of Topic, Person, Source, or Location (which can be extended in
the future...)
So, a high-level pseudo-XML would look like:
<interest>
<object> ... </object>
<relevance> 0.2 </relevance>
<link> http://more.here </link>
<origin>http://my-generator.com</origin>
</interest>
and <object> could contain anyone of these four:
<topic> Australian Wine </topic>
<source> <feed>http://ex.com/atom</feed> <imt>app/xml+atm</imt></
source>
<person> Marilyn Monroe </person>
<location> <place> Gold Coast</place><long> 23.2 </long><lat> 22.33 </
lat></location>
If you wanted to add a Person to the Source, we can link the
<interest> elements with IDs:
<interest id="mdrudge">....
<interest>
<source> <feed>http://ex.com/atom</feed> <person idref="#mdrudge">
</source>
Thanks for the opportunity to post these questions and feedback....
Cheers...
Dr Renato Iannella
Principal Scientist, National ICT Australia (NICTA)
Level 5, Axon Building #47, Staff House Rd, St Lucia, QLD, 4072,
AUSTRALIA
[t] +61 7 3300 8520 [f] +61 7 3300 4820 [m] +61 4 1313 2206
[e] ren...@nicta.com.au [w] http://nicta.com.au
[im] skype:riannella aim:renatoi2003
[1] <http://groups.google.com/group/apml-public/web/apml-1-0-draft-1>
Paul Jones
Sep 19, 2008, 3:21:43 AM9/19/08
to apml-...@googlegroups.com
Hi Renato,
First up, I just wanted to thank for you all your comments. They were certainly quite helpful in provoking some thoughts, and I believe there is actually quite a deal that the group can take on from them in terms of where we might be able to simplify some things, and also how we can solve some our current issues.
On Fri, Sep 19, 2008 at 4:10 AM, Renato Iannella <rian...@gmail.com> wrote:
1 - Are there any Use Cases and/or Scenarios that are driving the
design decisions for APML?
Many of the people participating have their own internal cases I believe, but there isn't anything formal produced.
Section 4.0:
2 - Why the use of the <Head><Title><Body> structure - seems very HTML-
ish - and not really required for an XML structure?
This has indeed been mentioned by a number of others, and the Draft 2 that I'm working does actually eliminate many of these tags in favour of a simplified structure.
3 - In the Document Head <Target> element, did you consider just using
a URI instead of the additional attribute type for "email",
"emailhash" and "url". That is, the URI can tell you the type:
mailto:f...@email.com
md5:34fwef3f3434
http://ex.com
That is actually quite an interesting suggestion - I'll consider that for simplifying that node.
Section 5.2 and 5.3:
4 - Why is there such an "explicit" separation of Implicit and
Explicit data? What if the data originated as implicit (auto-
generated) then updated by a human?
The separation generally comes down to the intended way that applications should present the data to the user. In the case you suggest, I've always figured that the application should remove it from implicit and add it to explicit if the user "interacts" with that data in any way.
Section 5.4:
5 - Why use the term "Concept" and not "Interest" (as Concept seems
more abstract and we want to express real areas of interest - which is
the core of APML spec)?
The term concept was simply the wording chosen in a very early version of APML, and has just stuck with us the whole way.
6 - Why use the attribute "key" as this implies uniqueness, which the
value may not be? Perhaps "term" or "topic" instead?
I believe we introduced the key attribute in 0.6, with the intent of unifying the "unique-key" across different element types. My take was always that it should be unique within a single application - so in the case of implicit data where multiple applications may generate it, the combination of source and key would provided a primary key.
7 - Why use the attribute "value" as it really is "relevance" (the
former implies the value for the element)?
Again, this was just early wording. I do actually like your terminology though, so depending upon just how different I can bring myself to make Draft 2, I might try them out...
8 - Why is "rdf:about" used here and "Link" used in People for the
same purpose?
(Also, did you want to introduce a new namespace?)
I'm sure as you'd note, there are quite a number of RDF supporters working within the APML group; and they have validly hilighted the power of RDF in this context. The balance is always in attempting to reduce complexity whilst still providing the best interoperability with the other formats (especially linked data ones) and tools. I felt that the use of the "rdf:about" attribute had the benefit of being self-documenting - if we're going to introduce linked data semantics, then we may as well introduce the linked data semantics that have already been worked on for quite some time.
In the case of the second draft, I've been considering taking on board some previous comments about not having quite so many nodes, and simply having the metadata on the nodes reflect the purpose. So perhaps instead of person and location, the concept node simply contains prescribed attributes about a person or location.
Section 5.5:
9 - I wanted clarify the example on this section. It seems to say that
you are not interested in the Source (-0.5) but are somewhat
interested in the Author (+0.2)?
Ummm... Thats probably just a bad example...
10 - What not reuse the People structure for Author?
That is quite plausible.
Section 5.7:
11 - You may need to be explicit on the default coordinate reference
system when using long/lats. Usually WGS84, but there are others.
I'm actually wondering whether the co-ordinate information provided by the Dublin Core metadata set would be a better place to define these from?
There has been some quite recent discussion about the topics of different formats; and I do believe at one point someone did do up a generalised model. This one does look quite good, and could actually provide a good solution to pre-unifying the work that is wanted to be done on the RDF-version of the schema - especially given that it may indeed make it possible to have two way transformations (Trent - thoughts on this??).
Perhaps it may even be a good idea for us, as a whole group, to consider developing a fuller version of this model; and then move onto considering the actual formats?
Thanks for the opportunity to post these questions and feedback....
Thank you for providing it!
Paul.
Renato Iannella
Sep 21, 2008, 9:27:23 PM9/21/08
to apml-...@googlegroups.com
On 19 Sep 2008, at 17:21, Paul Jones wrote:
> I'm actually wondering whether the co-ordinate information provided
> by the Dublin Core metadata set would be a better place to define
> these from?
DC just has Spatial [1] but it does not mention any CRS....that is, if
there is a need for a long/lat....
> Perhaps it may even be a good idea for us, as a whole group, to
> consider developing a fuller version of this model; and then move
> onto considering the actual formats?
From my experiences, it is a good idea to develop an Information
Model that is independent from any encodings (XML Schema and RDF/XML
etc). Then map to appropriate encoding(s) that the communities require.
Renato
NICTA
[1] <http://dublincore.org/documents/dcmi-terms/#terms-spatial>
Reply all
Reply to author
Forward
0 new messages