Initial Draft of APML 1.0
9 views
Skip to first unread message
Paul Jones
Aug 8, 2008, 12:14:28 PM8/8/08
to apml-...@googlegroups.com
Hi All,
This comes with a very large fore note: This is a very early draft only, and nothing is set in stone. Given that the community is obviously itching to start seeing APML 1.0 progress, I felt that it would be an appropriate time to release this and assist in structuring the discussion. I intend to follow this with a few more emails that detail individual sections I believe need substantial addressing.
The draft is located at: http://groups.google.com/group/apml-public/web/apml-1-0-draft-1
Cheers,
Paul.
This comes with a very large fore note: This is a very early draft only, and nothing is set in stone. Given that the community is obviously itching to start seeing APML 1.0 progress, I felt that it would be an appropriate time to release this and assist in structuring the discussion. I intend to follow this with a few more emails that detail individual sections I believe need substantial addressing.
The draft is located at: http://groups.google.com/group/apml-public/web/apml-1-0-draft-1
Cheers,
Paul.
Ash Angell
Aug 8, 2008, 9:27:03 PM8/8/08
to apml-...@googlegroups.com
Paul I like the specific I think it has a number of significant semantic advantages over 0.6 - my only concern is the location node, which I feel should be x, y (instead of long/lat) and should probably be always expressed in decimal degrees. the other value it requires, is a distance measurement (in meters) which represents the radius from the specified coordinates. Not perfect, but I feel its probably close enough for now and could be fine tuned in a future version.
Ash
Ash
Mason Lee
Aug 9, 2008, 5:12:17 AM8/9/08
to apml-...@googlegroups.com
(Hi everybody! My name is Mason and I'm a lurker on this list. Paul, thanks for posting the 1.0 outline and talking points!)
Re: Location
For what it's worth, geo-location is most commonly expressed as:
Longitude (Decimal Degrees)
Elevation (Meters from mean sea-level)
Radius (Meters)
Re: RDF and Concepts
I have a question. I like the RDF-direction that Tim described in his recent post and others have seconded: locations and people are just "concepts". However, does it follow that the APML group should not attempt to define or officially adopt some useful minimum concept ontology? Agreeing on what is a Person, a Time, a Geo-Location, etc. would go a long way towards making APML useful 'out of the box'.
Is the APML goal simply to define "The Ontology of Human Attention Itself, as Useful to Computerized Systems", or is it also a goal to officially adopt and promote a basic minimal ontology of concepts to help get everything off the ground? In my mind these are two separate missions.
Cheers,
Mason
Elias Bizannes
Aug 10, 2008, 7:42:19 AM8/10/08
to APML.Public.General
Hi,
Some of my views.
Location node: will be brilliant to add that, as a way of adding
context to a concept due to the ambigiueties of language. But as a
standalone node, simply to show you are interested in a particular
location, it doesn't make sense. Well it does, but it also means you
now have set the expectation that future terms need defining which is
potential infinite. So I think location added as context, like a time
stamp, is brilliant. But any other reason, not good.
People node: Don't see the point. The same way a definition defines a
concept should be used to define a person.
Source node: I think this is relevant and should be included. Concept
(thing) and source (lots of related things) makes sense.
I think only concepts and sources should be in the core spec; and
extensions be added to specify clusters of concepts like locations,
people etc. It allows people to opt in to use these terms for
consistency, but doesn't mandate it, because forcing generators to
have to determine whether something is a concept, a person, a
location, a beer type...falls into the same traps that plague
taxonomies where one master category doesn't necessarily mean it's the
only way to clasify something. The data format should be different
from the data interpretator. I agree we need some consistent terms,
but not the core spec - make it in the extensions only, as a best
practice not a mandated practice.
Also, I don't get what's stopping us from making APML RDF? APML looks
more like microformats - pretty to humans, annoying for computers.
When I export my APML file, I don't look at the XML - I'd expect an
application ot create pretty dials interpreting it. We should be doing
it in a format that makes it easier for computers to manipulate,
interpret, use - not humans. I don't care how my e-mail is stored when
I send an e-mail - I just care that the e-mail gets sent to the
destination. I am not going ot pretend I am an expert in RDF or
parsing and the rest - but it just seems to make sense to use RDF.
Elias
> > On Sat, Aug 9, 2008 at 2:14 AM, Paul Jones <pauljone...@gmail.com>
Some of my views.
Location node: will be brilliant to add that, as a way of adding
context to a concept due to the ambigiueties of language. But as a
standalone node, simply to show you are interested in a particular
location, it doesn't make sense. Well it does, but it also means you
now have set the expectation that future terms need defining which is
potential infinite. So I think location added as context, like a time
stamp, is brilliant. But any other reason, not good.
People node: Don't see the point. The same way a definition defines a
concept should be used to define a person.
Source node: I think this is relevant and should be included. Concept
(thing) and source (lots of related things) makes sense.
I think only concepts and sources should be in the core spec; and
extensions be added to specify clusters of concepts like locations,
people etc. It allows people to opt in to use these terms for
consistency, but doesn't mandate it, because forcing generators to
have to determine whether something is a concept, a person, a
location, a beer type...falls into the same traps that plague
taxonomies where one master category doesn't necessarily mean it's the
only way to clasify something. The data format should be different
from the data interpretator. I agree we need some consistent terms,
but not the core spec - make it in the extensions only, as a best
practice not a mandated practice.
Also, I don't get what's stopping us from making APML RDF? APML looks
more like microformats - pretty to humans, annoying for computers.
When I export my APML file, I don't look at the XML - I'd expect an
application ot create pretty dials interpreting it. We should be doing
it in a format that makes it easier for computers to manipulate,
interpret, use - not humans. I don't care how my e-mail is stored when
I send an e-mail - I just care that the e-mail gets sent to the
destination. I am not going ot pretend I am an expert in RDF or
parsing and the rest - but it just seems to make sense to use RDF.
Elias
Paul Jones
Aug 10, 2008, 9:32:19 AM8/10/08
to apml-...@googlegroups.com
Hi Elias,
On Sun, Aug 10, 2008 at 12:42 PM, Elias Bizannes <elias.b...@gmail.com> wrote:
Location node: will be brilliant to add that, as a way of adding
context to a concept due to the ambigiueties of language. But as a
standalone node, simply to show you are interested in a particular
location, it doesn't make sense. Well it does, but it also means you
now have set the expectation that future terms need defining which is
potential infinite. So I think location added as context, like a time
stamp, is brilliant. But any other reason, not good.
People node: Don't see the point. The same way a definition defines a
concept should be used to define a person.
Source node: I think this is relevant and should be included. Concept
(thing) and source (lots of related things) makes sense.
I think only concepts and sources should be in the core spec; and
extensions be added to specify clusters of concepts like locations,
people etc. It allows people to opt in to use these terms for
consistency, but doesn't mandate it, because forcing generators to
have to determine whether something is a concept, a person, a
location, a beer type...falls into the same traps that plague
taxonomies where one master category doesn't necessarily mean it's the
only way to clasify something. The data format should be different
from the data interpretator. I agree we need some consistent terms,
but not the core spec - make it in the extensions only, as a best
practice not a mandated practice.
This is definitely something that we could explore. And I do agree that having a clearer way of illustrating that a Location is actually just a better defined Concept would be a good thing.
Also, I don't get what's stopping us from making APML RDF? APML looks
more like microformats - pretty to humans, annoying for computers.
When I export my APML file, I don't look at the XML - I'd expect an
application ot create pretty dials interpreting it. We should be doing
it in a format that makes it easier for computers to manipulate,
interpret, use - not humans. I don't care how my e-mail is stored when
I send an e-mail - I just care that the e-mail gets sent to the
destination. I am not going ot pretend I am an expert in RDF or
parsing and the rest - but it just seems to make sense to use RDF.
And here's the part where ours views diverge. Given that I've written a number of apps built on top of APML (and other formats), saying that APML needn't be human readable is definitely a mistake. Developers spend a lot of time looking at the raw formats, so making them more difficult to read or write is an incredibly good way of discouraging people from using them. Email and HTTP are good examples - they are both actually interpretable to fix should you need to inspect.
I, personally, don't see APML as being hard for computers. It is well-formed, well-ruled XML. Listing every concept in the document can be done with a trivial xpath query.
Paul.
Chris Saad
Aug 10, 2008, 10:53:55 AM8/10/08
to apml-...@googlegroups.com
Having discussed this at length with Paul - the goal for adding people and places is clear for me.
The idea is that attention is much like a good story - Who, What, Where, When and How.
Who - Person
What - Concept
Where - Location
When - This might be interesting?
How - Source (how the content came to you).
This seems to me a fairly elegant way of describing the types of entities that a user pays Attention to.
Chris
The idea is that attention is much like a good story - Who, What, Where, When and How.
Who - Person
What - Concept
Where - Location
When - This might be interesting?
How - Source (how the content came to you).
This seems to me a fairly elegant way of describing the types of entities that a user pays Attention to.
Chris
--
Chris Saad
FaradayMedia - For Audiences of One
Particls - Are You Paying Attention?
Engagd - The Open Attention Platform
Media 2.0 Workgroup - Social, Democratic, Distributed
APML - Your Attention Profile
DataPortability - Connect, Control, Share, Remix
Chris Saad
FaradayMedia - For Audiences of One
Particls - Are You Paying Attention?
Engagd - The Open Attention Platform
Media 2.0 Workgroup - Social, Democratic, Distributed
APML - Your Attention Profile
DataPortability - Connect, Control, Share, Remix
Elias Bizannes
Aug 11, 2008, 5:27:03 AM8/11/08
to APML.Public.General
Isn't a a "who" simply a subset of a "what"? Location, as I said
above, is awesome if it's in the context of of the concept (the what),
not as standalone special case concept.
On Aug 11, 12:53 am, "Chris Saad" <chris.s...@gmail.com> wrote:
> Having discussed this at length with Paul - the goal for adding people and
> places is clear for me.
>
> The idea is that attention is much like a good story - Who, What, Where,
> When and How.
>
> Who - Person
> What - Concept
> Where - Location
> When - This might be interesting?
> How - Source (how the content came to you).
>
> This seems to me a fairly elegant way of describing the types of entities
> that a user pays Attention to.
>
> Chris
>
>
>
>
>
> On Sun, Aug 10, 2008 at 6:32 AM, Paul Jones <pauljone...@gmail.com> wrote:
> > Hi Elias,
>
> > On Sun, Aug 10, 2008 at 12:42 PM, Elias Bizannes <elias.bizan...@gmail.com
> DataPortability - Connect, Control, Share, Remix- Hide quoted text -
>
> - Show quoted text -
above, is awesome if it's in the context of of the concept (the what),
not as standalone special case concept.
On Aug 11, 12:53 am, "Chris Saad" <chris.s...@gmail.com> wrote:
> Having discussed this at length with Paul - the goal for adding people and
> places is clear for me.
>
> The idea is that attention is much like a good story - Who, What, Where,
> When and How.
>
> Who - Person
> What - Concept
> Where - Location
> When - This might be interesting?
> How - Source (how the content came to you).
>
> This seems to me a fairly elegant way of describing the types of entities
> that a user pays Attention to.
>
> Chris
>
>
>
>
>
> On Sun, Aug 10, 2008 at 6:32 AM, Paul Jones <pauljone...@gmail.com> wrote:
> > Hi Elias,
>
>
> - Show quoted text -
Mason Lee
Aug 11, 2008, 5:55:52 AM8/11/08
to apml-...@googlegroups.com
Elias, that's what I would think: People and Locations are just
subclasses of Concept. I would think APML should focus first on the
ontology of human attention with respect to computer systems, and not
so much on the ontology of what is being paid attention to. These are
two separate missions.
subclasses of Concept. I would think APML should focus first on the
ontology of human attention with respect to computer systems, and not
so much on the ontology of what is being paid attention to. These are
two separate missions.
Also, if you want to add Location (lat/long/elevation/radius) as a
standardized qualifier to Concepts, should you add TimeRange as well?
and Color, etc? Or are location and time range (and color, etc)
qualifiers also just concepts? (Perhaps Concepts then could be
nested, or could directly reference other Concepts in the AMPL, or we
need a new "qualifier" node.)
--Mason
scottw
Aug 12, 2008, 6:01:49 AM8/12/08
to APML.Public.General
The empty grouping elements such as <concepts>, <sources> and the like
don't really aid either processing or readability, are rather "old
fashioned" in terms of current serialization practices, and have to be
actively stripped out of RDF serialization. A flat list of entries
would process easily, be less verbose and less "bushy".
Likewise <head> and <body> are redundant. The <head> properties are
all properties of <apml> (the document); the rest are properties of
<profiles>. You aren't going to confuse them without having <head> and
<body>.
So this would mean a structure like:
apml
-title
-generator
-target
-profile
--concept
--concept
--source
-profile
...
(I think it may have been Tim Bray who once commented that a standard
isn't done until you've removed absolutely everything you possibly
can, and what remains still works...)
don't really aid either processing or readability, are rather "old
fashioned" in terms of current serialization practices, and have to be
actively stripped out of RDF serialization. A flat list of entries
would process easily, be less verbose and less "bushy".
Likewise <head> and <body> are redundant. The <head> properties are
all properties of <apml> (the document); the rest are properties of
<profiles>. You aren't going to confuse them without having <head> and
<body>.
So this would mean a structure like:
apml
-title
-generator
-target
-profile
--concept
--concept
--source
-profile
...
(I think it may have been Tim Bray who once commented that a standard
isn't done until you've removed absolutely everything you possibly
can, and what remains still works...)
gdupont
Aug 13, 2008, 8:00:46 AM8/13/08
to APML.Public.General
Hi all,
I just lost my magnificent post where I found all the solutions to
everything... Whatever I'll have to rewrite it.
So following Scott remarks, I suggest that APML avoid to define to
much things in depth. I like the What/where/... approach suggested by
Chris, but we should stick on simple concepts presentation and adding
an optional type attribute to specify which kind of entity we may
encounter. For instance :
<concepts>
<concept key="dupont" value="0.5" type="company"
rdf:about="http://en.wikipedia.org/wiki/DuPont" />
<concept key="dupont" value="0.5" type="location"
rdf:about="http://en.wikipedia.org/wiki/Dupont%2C_Colorado" />
<concept key="dupont" value="0.5" type="people"
rdf:about="http://en.wikipedia.org/wiki/Pierre_Dupont" />
<concept key="dupont" value="0.5" type="music band"
rdf:about="http://en.wikipedia.org/wiki/Dupont_(band)" />
</concepts>
IMHO this is simpler and you should avoid to redefine thing such as
location which are complex to handle and out of APML scope. Key is a
human understandable title, rdf:about is the uri of and RDF source (in
my example it's not, by you all understand) and type refine the entity
type. We could either make a controlled list of type and let it free
and put another URI there.
Then I'm a bit confuse by the Source markup. Does it define the
content source of a concept ? The application which produce the
concept ? Both of them were useful and in spec 0.6 we had application
and "from" attribute. that was clear. Any motivation behind this
change ? We could make it simpler by grouping the application and
sources definition together : either it is link in a concept (using
from attribute or internal markup), then it is a content source,
either it is linked in the implicit/explicit data from attribute and
then it is an application/service. In both cases the value reflect the
reliability or trust in the source.
An example :
<apml>
<title>my APML</title>
<generator>http://myAPMLgeneraor.org</generator>
<target>23FGACB2D2</target>
<profiles>
<profile name="home" >
<implicitdata>
<concepts>
<concept key="dupont" value="0.5" type="company"
rdf:about="http://en.wikipedia.org/wiki/DuPont" />
<concept key="dupont" value="0.5" type="location"
rdf:about="http://en.wikipedia.org/wiki/Dupont%2C_Colorado" />
<concept key="dupont" value="0.5" type="people"
rdf:about="http://en.wikipedia.org/wiki/Pierre_Dupont" />
<concept key="dupont" value="0.5" type="music band"
rdf:about="http://en.wikipedia.org/wiki/Dupont_(band)" >
<from key="http://www.myspace.com/dupontsweden"/>
<from key="http://www.youtube.com/watch?
v=OsDVj53vLKY"/>
</concept>
</concepts>
</implicitdata>
<sources>
<source key="http://www.myspace.com/dupontsweden"
type="content" value="0.9"/>
<source key="http://www.youtube.com/watch?v=OsDVj53vLKY"
type="content" value="0.5"/>
<source key="adaptiveBroswer" type="application" value="1"/>
</sources>
</profile>
</profiles>
</apml>
Finally, some about the explicit/implicit frontier. Reading the spec
it looks like that "Explicit Data is shared between all applications"
and result from the direct involvement of target. But it is somehow
difficult to have such statement. For instance when rating an item on
a website, you could imaging a process that automatically produce that
APML that correspond to that action. Is it explicit ? Yes because you
rate directly. But what about the construction of group APML that
results from a group (fusion of APML). Are the data implicit or
explicit ? If you use the rating data yes, but it is still computed to
produce the score... So it is more implicit than explicit from the
group POV. Well I don't really know.
What about another segmentation of data. Instead of explicit/implicit
having user generated / computed plus private/public ...
gd
I just lost my magnificent post where I found all the solutions to
everything... Whatever I'll have to rewrite it.
So following Scott remarks, I suggest that APML avoid to define to
much things in depth. I like the What/where/... approach suggested by
Chris, but we should stick on simple concepts presentation and adding
an optional type attribute to specify which kind of entity we may
encounter. For instance :
<concepts>
<concept key="dupont" value="0.5" type="company"
rdf:about="http://en.wikipedia.org/wiki/DuPont" />
<concept key="dupont" value="0.5" type="location"
rdf:about="http://en.wikipedia.org/wiki/Dupont%2C_Colorado" />
<concept key="dupont" value="0.5" type="people"
rdf:about="http://en.wikipedia.org/wiki/Pierre_Dupont" />
<concept key="dupont" value="0.5" type="music band"
rdf:about="http://en.wikipedia.org/wiki/Dupont_(band)" />
</concepts>
IMHO this is simpler and you should avoid to redefine thing such as
location which are complex to handle and out of APML scope. Key is a
human understandable title, rdf:about is the uri of and RDF source (in
my example it's not, by you all understand) and type refine the entity
type. We could either make a controlled list of type and let it free
and put another URI there.
Then I'm a bit confuse by the Source markup. Does it define the
content source of a concept ? The application which produce the
concept ? Both of them were useful and in spec 0.6 we had application
and "from" attribute. that was clear. Any motivation behind this
change ? We could make it simpler by grouping the application and
sources definition together : either it is link in a concept (using
from attribute or internal markup), then it is a content source,
either it is linked in the implicit/explicit data from attribute and
then it is an application/service. In both cases the value reflect the
reliability or trust in the source.
An example :
<apml>
<title>my APML</title>
<generator>http://myAPMLgeneraor.org</generator>
<target>23FGACB2D2</target>
<profiles>
<profile name="home" >
<implicitdata>
<concepts>
<concept key="dupont" value="0.5" type="company"
rdf:about="http://en.wikipedia.org/wiki/DuPont" />
<concept key="dupont" value="0.5" type="location"
rdf:about="http://en.wikipedia.org/wiki/Dupont%2C_Colorado" />
<concept key="dupont" value="0.5" type="people"
rdf:about="http://en.wikipedia.org/wiki/Pierre_Dupont" />
<concept key="dupont" value="0.5" type="music band"
rdf:about="http://en.wikipedia.org/wiki/Dupont_(band)" >
<from key="http://www.myspace.com/dupontsweden"/>
<from key="http://www.youtube.com/watch?
v=OsDVj53vLKY"/>
</concept>
</concepts>
</implicitdata>
<sources>
<source key="http://www.myspace.com/dupontsweden"
type="content" value="0.9"/>
<source key="http://www.youtube.com/watch?v=OsDVj53vLKY"
type="content" value="0.5"/>
<source key="adaptiveBroswer" type="application" value="1"/>
</sources>
</profile>
</profiles>
</apml>
Finally, some about the explicit/implicit frontier. Reading the spec
it looks like that "Explicit Data is shared between all applications"
and result from the direct involvement of target. But it is somehow
difficult to have such statement. For instance when rating an item on
a website, you could imaging a process that automatically produce that
APML that correspond to that action. Is it explicit ? Yes because you
rate directly. But what about the construction of group APML that
results from a group (fusion of APML). Are the data implicit or
explicit ? If you use the rating data yes, but it is still computed to
produce the score... So it is more implicit than explicit from the
group POV. Well I don't really know.
What about another segmentation of data. Instead of explicit/implicit
having user generated / computed plus private/public ...
gd
scottw
Aug 14, 2008, 6:03:38 AM8/14/08
to APML.Public.General
Sorry for harping on about what may seem a bit trivial, but is this:
<apml>
<title>my APML</title>
<generator>http://myAPMLgeneraor.org</generator>
<target>23FGACB2D2</target>
<profile name="home" >
<implicitdata>
</profile>
</apml>
... any less readable for the absence of the various "pluralized"
tags? (Not to mention no more head and body...)
S
PS gd I have your missing post! You must have replied direct to me - I
shall forward it back to you...
<apml>
<title>my APML</title>
<generator>http://myAPMLgeneraor.org</generator>
<target>23FGACB2D2</target>
<implicitdata>
<concept key="dupont" value="0.5" type="company"
rdf:about="http://en.wikipedia.org/wiki/DuPont" />
<concept key="dupont" value="0.5" type="location"
rdf:about="http://en.wikipedia.org/wiki/Dupont%2C_Colorado" />
<concept key="dupont" value="0.5" type="people"
rdf:about="http://en.wikipedia.org/wiki/Pierre_Dupont" />
<concept key="dupont" value="0.5" type="music band"
rdf:about="http://en.wikipedia.org/wiki/Dupont_(band)" >
<from key="http://www.myspace.com/dupontsweden"/>
<from key="http://www.youtube.com/watch?
v=OsDVj53vLKY"/>
</concept>
rdf:about="http://en.wikipedia.org/wiki/DuPont" />
<concept key="dupont" value="0.5" type="location"
rdf:about="http://en.wikipedia.org/wiki/Dupont%2C_Colorado" />
<concept key="dupont" value="0.5" type="people"
rdf:about="http://en.wikipedia.org/wiki/Pierre_Dupont" />
<concept key="dupont" value="0.5" type="music band"
rdf:about="http://en.wikipedia.org/wiki/Dupont_(band)" >
<from key="http://www.myspace.com/dupontsweden"/>
<from key="http://www.youtube.com/watch?
v=OsDVj53vLKY"/>
</concept>
<source key="http://www.myspace.com/dupontsweden"
type="content" value="0.9"/>
<source key="http://www.youtube.com/watch?v=OsDVj53vLKY"
type="content" value="0.5"/>
<source key="adaptiveBroswer" type="application"
value="1"/>
</implicitdata>
type="content" value="0.9"/>
<source key="http://www.youtube.com/watch?v=OsDVj53vLKY"
type="content" value="0.5"/>
<source key="adaptiveBroswer" type="application"
value="1"/>
</profile>
</apml>
... any less readable for the absence of the various "pluralized"
tags? (Not to mention no more head and body...)
S
PS gd I have your missing post! You must have replied direct to me - I
shall forward it back to you...
gdupont
Aug 18, 2008, 2:57:51 AM8/18/08
to APML.Public.General
Actually, this is half hand-made example, thus it may contains
mistakes such as the miss of pluralized tags.
mistakes such as the miss of pluralized tags.
scottw
Aug 18, 2008, 5:10:51 AM8/18/08
to APML.Public.General
Ah, but missing the pluralized tags is a good mistake, it shows how
unnecessary they are :-)
unnecessary they are :-)
gdupont
Aug 18, 2008, 7:16:21 AM8/18/08
to APML.Public.General
Well, I don't know. I think this is the same problem with head/body
tags : depending on your XML parser, you may find them useful or
unnecessary. I don't have particular preferences except that we may
have lighter APML without them (but the gain is also light...).
I do agree with "a standard isn't done until you've removed absolutely
everything you possibly can [...]".
tags : depending on your XML parser, you may find them useful or
unnecessary. I don't have particular preferences except that we may
have lighter APML without them (but the gain is also light...).
I do agree with "a standard isn't done until you've removed absolutely
everything you possibly can [...]".
Reply all
Reply to author
Forward
0 new messages