APML 1.0 and RDF (was: APML-RDF)
3 views
Skip to first unread message
Paul Jones
Apr 28, 2008, 4:09:30 AM4/28/08
to apml-...@googlegroups.com
Hi Everyone,
So I've been following this conversation, and I certainly find the APML-RDF integration quite interesting.
My preference is to not deprecate the standard XML form of APML, and instead propose the APML-RDF be defined as a standard "view" on APML (similarly to the APML-JSON transform specified by David Novakovic).
I'm planning to generate a public draft of APML 1.0 quite soon, with the main inclusions over 0.6 being
- An official extension mechanism, whereby the standard can be extended post-1.0 with features such as official "views" (JSON, RDF, etc), or the addition of more inline elements (such as the proposed inline RDF content).
- The addition of people and places elements.
- Cleanup of the <head> element. (For note, if there are other proposals for the name of this element, I'm open to them).
My hope is that, despite there being some "breaking" changes in 1.0 vs 0.6, that we'll be able to publish something like an XSLT that will transform from 0.6 and 1.0 (and maybe even partially back) to ensure that adoption doesn't end up too splintered.
Thoughts?
Paul.
So I've been following this conversation, and I certainly find the APML-RDF integration quite interesting.
My preference is to not deprecate the standard XML form of APML, and instead propose the APML-RDF be defined as a standard "view" on APML (similarly to the APML-JSON transform specified by David Novakovic).
I'm planning to generate a public draft of APML 1.0 quite soon, with the main inclusions over 0.6 being
- An official extension mechanism, whereby the standard can be extended post-1.0 with features such as official "views" (JSON, RDF, etc), or the addition of more inline elements (such as the proposed inline RDF content).
- The addition of people and places elements.
- Cleanup of the <head> element. (For note, if there are other proposals for the name of this element, I'm open to them).
My hope is that, despite there being some "breaking" changes in 1.0 vs 0.6, that we'll be able to publish something like an XSLT that will transform from 0.6 and 1.0 (and maybe even partially back) to ensure that adoption doesn't end up too splintered.
Thoughts?
Paul.
On Mon, Apr 28, 2008 at 8:46 AM, David Novakovic <davidno...@gmail.com> wrote:
APML v1 is going to break backwards compat. We might as well add these
things there.
David
John Breslin wrote:
> Great stuff Ger, Trent, Scott -
>
> I had in mind that we should try and evolve APML-RDF along with the main
> APML - so to have a clear table of what maps to what would help -
>
> Forking would be a bad idea I think and I never intended it to be a
> replacement - but since it is RDF extra things can be added that may not
> work so well in the XML definition (without breaking the mappings of
> course)...
>
> Anyway, looking forward to further feedback, thanks!
>
> John.
> --
> gdupont wrote:
>
>> Good proposal indeed better that my own because its full RDF.
>>
>> But I'm concerns with the use of this model because of the extend RDF
>> user. I'm pro-RDF, but as far as I understand, at first the APML
>> community was not so at ease with the idea of having RDF definition
>> for APML. The idea was to keep simple things so standard XML with XSD.
>> Now we are moving into RDF and RDFS.
>>
>> It sounds good to me, but I would like to read the feedback of other
>> APML suers/designer/community member. Do they plan to use this ? Is
>> everibody OK if we move to RDF ?
>>
>> I see many many benefits of course (among others : link to FOAF for
>> user's description, SIOC for specific application description and
>> external ontology as terminology to disambiguate specific terms...)
>>
>> So last thing if we go in that direction : you propose to replace the
>> concept "key" by the dc:title property. So the system that will
>> analyse the APML will have to determinate itself this is a simple term
>> (Literal) or an external resource. that could be easily done in RDF
>> but my own experience is that we may constraint it a bit to avoid that
>> people add resource URI as Literal (ie having URI in the String of the
>> Literal instead of defining a real resource). What do you think ?
>>
>> gd
>>
>>
>>
>> On Apr 23, 12:53 pm, scottw <scott.bradley.wil...@gmail.com> wrote:
>>
>>
>>> I think the approach you've taken with this is maybe a bit too
>>> literal. A more free RDF interpretation would look something like:
>>>
>>> AttentionProfileDocument
>>> .apml:contains range: [AttentionProfile]
>>> .dc:title
>>> .dcterms:source
>>> .dcterms:created
>>>
>>> AttentionProfile
>>> .dc:title
>>> .apml:item range: [Concept | Source]
>>>
>>> Concept
>>> .dc:title
>>> .dc:type range:literal [implicit | explicit]
>>> .dcterms:source
>>> .dcterms:modified
>>> .apml:weight
>>>
>>> Source
>>> .dc:title
>>> .dc:type range: literal [implicit | explicit]
>>> .dcterms:source
>>> .dcterms:modified
>>> .apml:weight
>>>
>>> So the APML namespace only needs to define 4 classes and 3 properties,
>>> which can be done in a very, very small RDFS. Things like "head" and
>>> "body" and the grouping mechanisms like "sources" and "concepts" are
>>> an artifact of the (outdated IMHO) OPML syntax and have no well-
>>> defined semantic value worth representing in RDF . In fact, they
>>> probably should be dropped from the APML XML serialization too :)
>>>
>>> Note I replaced here "Head" with "AttentionProfileDocument" - in that
>>> it is a resource containing metadata about the document that contains
>>> the profiles. Another resource class could also identify the
>>> collection of profiles itself separately from the document (i.e.
>>> abstractly), but I've left this out for simplicity. (Google OAI-ORE
>>> for an example of this concept used in practice)
>>>
>>> S.
>>>
>>>
>>>
>>
>>
>
>
>
David Novakovic
Apr 28, 2008, 4:27:58 AM4/28/08
to apml-...@googlegroups.com
There is definitely merit in keeping a pure XML schema version of APML.
It's easy to grok and reduces the barrier to entry for people new to the
standard.
It's easy to grok and reduces the barrier to entry for people new to the
standard.
I think a unified release of APML V1 + extensions would help with
providing a unified picture to people observing the standards, and
newcomers who need a good overview from a single press release. It will
also get people in the greater DP community an overview in the form of a
progress report about what the attention layer in the DP stack is doing.
Create some awareness as well as move the spec forward.
What we'd need to do is agree on the spec for v1, then specify the
extensions. From there we can combine them into a single PR that will be
release to the wider community.
Just some thoughts - open to corrections + criticisms. :)
David
John Breslin
Apr 28, 2008, 4:30:00 AM4/28/08
to apml-...@googlegroups.com
>
> My preference is to not deprecate the standard XML form of APML, and
> instead propose the APML-RDF be defined as a standard "view" on APML
> (similarly to the APML-JSON transform specified by David Novakovic).
>
John.
--
J. Trent Adams
Apr 28, 2008, 9:00:58 AM4/28/08
to APML.Public.General
I agree with maintaining a "friendly" view of APML for the non-RDF
speakers in the crowd.
I believe it's going to be key to wider adoption not to scare people
away with the arcana required to support the richer experience.
Hopefully, then, after getting their feet wet with the "APML Lite"
view, they'll begin to see the power under the covers.
BTW - Forgive my ignorance... but is there a date by which comments to
APML v.1 must be submitted for review? Last I heard it was going to
be early this year, but then the DataPortability Project took off and
I can't seem to find the most up-to-date milestone schedule for the
review process. Any pointers?
Thanks,
=jtrentadams
Paul Jones
Apr 28, 2008, 9:20:02 AM4/28/08
to apml-...@googlegroups.com
There isn't really a hard date. My intention is to release a draft quite soon encompassing the discussion to-date.
Paul.
Paul.
TSchultz55
Apr 28, 2008, 9:25:01 AM4/28/08
to APML.Public.General
Great ideas all around.
Sounds like we're looking at a situation similar to the various RSS
formats out there (i.e. RDF Site Summary (1.0) vs. Really Simple
Syndication (2.0)). In most cases, RSS clients completely abstract
what version it is currently reading, so the user is normally
oblivious to the different formats.
Consider this little snippet: http://www.mnot.net/rss/tutorial/#Choose
But I agree Trent - the more RDF out there in the cloud, the better
the vision of LD/SW
Sounds like we're looking at a situation similar to the various RSS
formats out there (i.e. RDF Site Summary (1.0) vs. Really Simple
Syndication (2.0)). In most cases, RSS clients completely abstract
what version it is currently reading, so the user is normally
oblivious to the different formats.
Consider this little snippet: http://www.mnot.net/rss/tutorial/#Choose
But I agree Trent - the more RDF out there in the cloud, the better
the vision of LD/SW
TSchultz55
Apr 28, 2008, 9:34:11 AM4/28/08
to APML.Public.General
Ooops....hit send by accident. Here's a continuation:
But I agree Trent - the more RDF out there in the cloud, the better
the vision of LD/SW can be realized. And linking attention concepts
to URI's enables much more "intelligent" and robust APML agents. So
I'm all for it as well!
As long as the APML libraries can seamlessly work between the two
versions I don't see any problems. I'd certainly integrate it into
APMLStream.
But I agree Trent - the more RDF out there in the cloud, the better
to URI's enables much more "intelligent" and robust APML agents. So
I'm all for it as well!
As long as the APML libraries can seamlessly work between the two
versions I don't see any problems. I'd certainly integrate it into
APMLStream.
TSchultz55
Apr 28, 2008, 10:06:54 AM4/28/08
to APML.Public.General
Paul,
Any thoughts on possibly establishing a solid "cut off" date for
recommendations?
Tim
On Apr 28, 9:20 am, "Paul Jones" <pauljone...@gmail.com> wrote:
> There isn't really a hard date. My intention is to release a draft quite
> soon encompassing the discussion to-date.
>
> Paul.
>
> On Mon, Apr 28, 2008 at 2:00 PM, J. Trent Adams <jtrentad...@gmail.com>
Any thoughts on possibly establishing a solid "cut off" date for
recommendations?
Tim
On Apr 28, 9:20 am, "Paul Jones" <pauljone...@gmail.com> wrote:
> There isn't really a hard date. My intention is to release a draft quite
> soon encompassing the discussion to-date.
>
> Paul.
>
Paul Jones
Apr 28, 2008, 10:20:39 AM4/28/08
to apml-...@googlegroups.com
Certainly. I'd be quite interested in making that cut-off soon.
I think we might also be able to get moving if someone in the community would be able to help out with some of these specifications - especially in terms of drafting the extension process and perhaps the RDF extension specification.
Paul.
I think we might also be able to get moving if someone in the community would be able to help out with some of these specifications - especially in terms of drafting the extension process and perhaps the RDF extension specification.
Paul.
gdupont
Apr 29, 2008, 8:23:02 AM4/29/08
to APML.Public.General
The proposal for APML v1 sounds good to me as far as you keep possible
link to RDF at least with optionnal URI for keywords that define the
profile bones.
Following the discussion on the multiple view of APML, I'm thinking to
building a more general model, for instance an UML class diagramm,
that can serve as a guide and then propose several serialisation (XML,
RDF/XML, JSON, or any other...). This will be more a model-driven
approach which can be seen as being a bit more complicated but will
simplify the comprehension of the multiple serialisation mode.
What do you thing ?
gdupont
link to RDF at least with optionnal URI for keywords that define the
profile bones.
Following the discussion on the multiple view of APML, I'm thinking to
building a more general model, for instance an UML class diagramm,
that can serve as a guide and then propose several serialisation (XML,
RDF/XML, JSON, or any other...). This will be more a model-driven
approach which can be seen as being a bit more complicated but will
simplify the comprehension of the multiple serialisation mode.
What do you thing ?
gdupont
gdupont
Apr 29, 2008, 11:16:15 AM4/29/08
to APML.Public.General
scottw
May 13, 2008, 5:36:47 AM5/13/08
to APML.Public.General
If you have an abstract model expressed with some basic semantic rigor
(UML classes are fine) from which both the XML and RDF serializations
are derived, then you have the potential for automated mapping from
the XML to RDF, and possibly good-enough mapping back the other way.
GRRDL is also an option.
The APML UML model should be very, very simple; it will also show up
problems in the existing spec quite nicely.
(UML classes are fine) from which both the XML and RDF serializations
are derived, then you have the potential for automated mapping from
the XML to RDF, and possibly good-enough mapping back the other way.
GRRDL is also an option.
The APML UML model should be very, very simple; it will also show up
problems in the existing spec quite nicely.
scottw
May 13, 2008, 7:44:14 AM5/13/08
to APML.Public.General
Here's another strawman UML model that takes a more liberal approach
to the spec; the main observations I had with modelling APML were:
- "implicit" and "explicit" are perhaps better expressed as properties
of an item rather than containers for items, and reduces the number of
subclasses
- "head" and "body" don't easily translate into classes as they are
more an artifact of the OPML/HTML syntax
- a single Item superclass for Source and Concept is a useful
construct for enabling extensibility, but is not compatible with using
Implicit and Explicit container types
- it may be sensible to rename some properties for consistency with
other specs, such as Atom (GData) and Dublin Core
- I'm unsure of how the "Application" part of APML should be used so I
left it out of this model
- "from" I left as a String but I think was proposed as a URI
- I added an optional "identifier" URI as distinct from "title" String
as a way of disambiguating "key" while supporting URIs for concepts
http://zope.cetis.ac.uk/members/scott/resources/apml.png
Hopefully inspires a few ideas!
to the spec; the main observations I had with modelling APML were:
- "implicit" and "explicit" are perhaps better expressed as properties
of an item rather than containers for items, and reduces the number of
subclasses
- "head" and "body" don't easily translate into classes as they are
more an artifact of the OPML/HTML syntax
- a single Item superclass for Source and Concept is a useful
construct for enabling extensibility, but is not compatible with using
Implicit and Explicit container types
- it may be sensible to rename some properties for consistency with
other specs, such as Atom (GData) and Dublin Core
- I'm unsure of how the "Application" part of APML should be used so I
left it out of this model
- "from" I left as a String but I think was proposed as a URI
- I added an optional "identifier" URI as distinct from "title" String
as a way of disambiguating "key" while supporting URIs for concepts
http://zope.cetis.ac.uk/members/scott/resources/apml.png
Hopefully inspires a few ideas!
gdupont
May 14, 2008, 7:54:19 AM5/14/08
to APML.Public.General
Good to see some other proposal.
I agree on your main idea : keep it simple by reducing the number of
classes. My UML proposal was not perfect since especially about the
implicit/explicit part.
Your scheme seems good and introduces many changes from the actual
spec. But I don't understand the need to have all information in the
Item superclass and then have subclasses that does not introduce new
attributes. I'm thinking to something that mix the two and try to make
another proposal later.
gd
I agree on your main idea : keep it simple by reducing the number of
classes. My UML proposal was not perfect since especially about the
implicit/explicit part.
Your scheme seems good and introduces many changes from the actual
spec. But I don't understand the need to have all information in the
Item superclass and then have subclasses that does not introduce new
attributes. I'm thinking to something that mix the two and try to make
another proposal later.
gd
scottw
May 15, 2008, 8:13:45 AM5/15/08
to APML.Public.General
That sounds like an excellent idea - I don't have the history in this
group for understanding why some properties are on particular types
and not others, so didn't feel comfortable about being too specific!
On May 14, 12:54 pm, gdupont <ger.dup...@gmail.com> wrote:
> [...] But I don't understand the need to have all information in the
group for understanding why some properties are on particular types
and not others, so didn't feel comfortable about being too specific!
On May 14, 12:54 pm, gdupont <ger.dup...@gmail.com> wrote:
> [...] But I don't understand the need to have all information in the
TSchultz55
May 30, 2008, 11:11:07 AM5/30/08
to APML.Public.General
Been thinking more about this - could someone possibly post a small
example APML-RDF profile based on the current proposals? I'd be
really interested in seeing them.
Would be **HUGE** if one could query a SPARQL endpoint to retrieve
information about a pool of attention profiles: i.e. "How many people
have _explicitly_ listed _Linux_ as an interest over a value of
_0.5_?"
I'd really like to see APML-RDF become a reality. What do we need to
do further progress these ideas?
Cheers,
Tim
example APML-RDF profile based on the current proposals? I'd be
really interested in seeing them.
Would be **HUGE** if one could query a SPARQL endpoint to retrieve
information about a pool of attention profiles: i.e. "How many people
have _explicitly_ listed _Linux_ as an interest over a value of
_0.5_?"
I'd really like to see APML-RDF become a reality. What do we need to
do further progress these ideas?
Cheers,
Tim
scottw
Jun 3, 2008, 5:54:22 AM6/3/08
to APML.Public.General
Here's an example based on the UML I posted:
http://www.cetis.ac.uk/members/scott/resources/apml.xml
Though on reflection I think "AttentionProfileDocument" needs to
explicitly identify the resource whose profiles the document
describes, similar to the foaf:maker property on
foaf:PersonalProfileDocument. Perhaps an "apml:about" property might
reference a foaf:Person?
Still, should be possible to generate some more of these to test
SPARQLing.
S
http://www.cetis.ac.uk/members/scott/resources/apml.xml
Though on reflection I think "AttentionProfileDocument" needs to
explicitly identify the resource whose profiles the document
describes, similar to the foaf:maker property on
foaf:PersonalProfileDocument. Perhaps an "apml:about" property might
reference a foaf:Person?
Still, should be possible to generate some more of these to test
SPARQLing.
S
John Breslin
Jun 4, 2008, 4:25:58 AM6/4/08
to apml-...@googlegroups.com
Looks good Scott - as you said earlier, if we had a UML model then
this'd make it easier to produce the RDF spec...
this'd make it easier to produce the RDF spec...
Is anyone working on a UML model?
J.
--
--
Dr. John Breslin
DERI, NUI Galway
http://sw.deri.org/~jbreslin/
john.b...@deri.org
TSchultz55
Jun 5, 2008, 8:56:08 AM6/5/08
to APML.Public.General
Scott - looks great and thanks! I'm going to whip up a few more
examples, load it into the SPARQL endpoint on my blog, and test out
some queries - just to get a good feel for what we're looking at. I
can forward you the URL and read key to do the same if you'd like.
Tim
> john.bres...@deri.org
examples, load it into the SPARQL endpoint on my blog, and test out
some queries - just to get a good feel for what we're looking at. I
can forward you the URL and read key to do the same if you'd like.
Tim
scottw
Jun 7, 2008, 12:54:22 PM6/7/08
to APML.Public.General
Hi Tim,
I've added two more strawman examples, for exploring integration
between APML-RDF and FOAF
Example 2 replaces the APML person attributes with a reference to a
foaf:Person
(using a postulated "apml:about" tag - but is the PPDoc "about" me, or
should it really be the Profile thats "about" me? APML currently has a
one-subject-per-document model which fits the typical XML-based use
case - but in RDF wouldn't you be more likely to aggregate lots of
profiles of different people into the same graph?)
http://zope.cetis.ac.uk/members/scott/resources/apml_2.xml
Example 3 shows a foaf:Person with two linked APML Profiles
http://zope.cetis.ac.uk/members/scott/resources/apml_3.xml
(using a postulated "apml:attentionProfile" property on foaf:Person to
connect the person to each profile)
((if the link is between Person and Profile, then maybe a symmetrical
isProfileOf/hasProfile property pair might be more appropriate?))
Again be aware that these examples deviate from the published APML
spec!
S
I've added two more strawman examples, for exploring integration
between APML-RDF and FOAF
Example 2 replaces the APML person attributes with a reference to a
foaf:Person
(using a postulated "apml:about" tag - but is the PPDoc "about" me, or
should it really be the Profile thats "about" me? APML currently has a
one-subject-per-document model which fits the typical XML-based use
case - but in RDF wouldn't you be more likely to aggregate lots of
profiles of different people into the same graph?)
http://zope.cetis.ac.uk/members/scott/resources/apml_2.xml
Example 3 shows a foaf:Person with two linked APML Profiles
http://zope.cetis.ac.uk/members/scott/resources/apml_3.xml
(using a postulated "apml:attentionProfile" property on foaf:Person to
connect the person to each profile)
((if the link is between Person and Profile, then maybe a symmetrical
isProfileOf/hasProfile property pair might be more appropriate?))
Again be aware that these examples deviate from the published APML
spec!
S
J. Trent Adams
Jun 10, 2008, 11:20:13 AM6/10/08
to APML.Public.General
Scott -
After a quick glance, your examples dovetail nicely with similar ideas
I've been toying with. Oddly enough, I was trying to stay more within
the realm of the current APML spec and add RDF goodness to it, but it
kept creeping more into the RDF camp than I thought useful.
Now that I see your examples, I'm personally much more interested in
this type of approach (i.e. bridge the gap from the direction of RDF
to APML). I'd like to circle back and make sure all of the elements
from the current spec are captured, plus layer in a couple of
additional concepts from my sketches.
In response to your strawman, I'd raise my hand in support of this
direction.
Perpetually iterating,
Trent
------------------------
J. Trent Adams
=jtrentadams
About Me: http://xri.net/=jtrentadams/+about
Follow Me: http://twitter.com/jtrentadams
After a quick glance, your examples dovetail nicely with similar ideas
I've been toying with. Oddly enough, I was trying to stay more within
the realm of the current APML spec and add RDF goodness to it, but it
kept creeping more into the RDF camp than I thought useful.
Now that I see your examples, I'm personally much more interested in
this type of approach (i.e. bridge the gap from the direction of RDF
to APML). I'd like to circle back and make sure all of the elements
from the current spec are captured, plus layer in a couple of
additional concepts from my sketches.
In response to your strawman, I'd raise my hand in support of this
direction.
Perpetually iterating,
Trent
------------------------
J. Trent Adams
=jtrentadams
About Me: http://xri.net/=jtrentadams/+about
Follow Me: http://twitter.com/jtrentadams
Reply all
Reply to author
Forward
0 new messages