Support for an RDF Version

[J. Trent Adams]

APMLers -

Now that it seems as if APML v.1 as proposed by Paul is on the floor,
I'd be interested in a quick look ahead at the roadmap.

From my vantage point, while the current version appears to help
support some aspects of what we need, I'd like to revisit some of the
key points I'd raised earlier [1]. Specifically whether this group
sees value in an full RDF version on the near horizon.

I know that this work would go beyond the KISS mantra, and be a
significant divergence from the existing format. So that I can
effectively partition my time, however, it'd be great to go around the
room and see who'd like to commit to an RDF version of APML.

So, in short, anyone want to weigh in with a "yea" (+1) to commit to
it now, or a "nae" (-1) not at this time?

Thanks for the clarity,
Trent

[1] http://groups.google.com/group/apml-public/browse_thread/thread/226c567e9af6ff91?hl=en

---
J. Trent Adams
=jtrentadams

About: http://www.mediaslate.org/jtrentadams/
Follow: http://twitter.com/jtrentadams

[TSchultz55]

+1 yea for me.

We've identified some solid business cases for these ideas here and
would very much be interested in further exploration.

Cheers,

Tim

On Sep 11, 11:21 am, "J. Trent Adams" <jtrentad...@gmail.com> wrote:
> APMLers -
>
> Now that it seems as if APML v.1 as proposed by Paul is on the floor,
> I'd be interested in a quick look ahead at the roadmap.
>
> From my vantage point, while the current version appears to help
> support some aspects of what we need, I'd like to revisit some of the
> key points I'd raised earlier [1].  Specifically whether this group
> sees value in an full RDF version on the near horizon.
>
> I know that this work would go beyond the KISS mantra, and be a
> significant divergence from the existing format.  So that I can
> effectively partition my time, however, it'd be great to go around the
> room and see who'd like to commit to an RDF version of APML.
>
> So, in short, anyone want to weigh in with a "yea" (+1) to commit to
> it now, or a "nae" (-1) not at this time?
>
> Thanks for the clarity,
> Trent
>

> [1]http://groups.google.com/group/apml-public/browse_thread/thread/226c5...

[danielabarbosa]

I know i have not been involved in the day to day. but i would like to
put a +1 forward on this on seeing the value of a future RDF version.

I believe support from the RDF 'community' [1}] has already been
indicated and they perhaps should be reconnected with if they have not
been recently involved in APML specs.

[1]
http://groups.google.com/group/apml-public/msg/37cc6bf23563ffc7

[scottw]

+1 yea, I'm happy to continue contributing to an RDF version, and to
promote its use in a project I'm working on for the UK research
community

[gdupont]

[+1]

I'm already working on a rdf version export

[Daniel Renfer]

Another casual observer chiming in:

+1

It seems rather silly to have a framework for describing resources and not use RDF. There are good parsers out there for just about any language. It should be simple enough to get just the basic info out if you need it, while alowing for others to push it's capabilities to the limit.

Also, having an RDF-based APML ontology opens up the possibility of embedding attention profile information into HTML using RDFa.

[François Dongier]

+1     Keep it smart...

[J. Trent Adams]

Team APML -

That's a great show of support for the next logical evolution of APML
into something more context-rich.

Based on the fact that there's no dissent, I'll assume everyone who
didn't respond abstains and doesn't violently oppose the move to begin
working together as a group on an RDF representation of APML.

To capitalize on the interest, I'll see if we can get some space in
the official wiki to gather our notes. That way we can use the list
to discuss details, while we publish draft and consensus documents so
we're always on the same page. Also, does it make sense to lay out a
few teleconference times in the coming weeks when we could talk
together?

Any other suggestions to help make this a reality?

Cheers,
Trent


On Sep 12, 8:43 am, "François Dongier" <francois.dong...@gmail.com>
wrote:
> +1     Keep it smart...

>
> On Fri, Sep 12, 2008 at 2:07 PM, Daniel Renfer <d...@kronkltd.net> wrote:
> > Another casual observer chiming in:
>
> > +1
>
> > It seems rather silly to have a framework for describing resources and not
> > use RDF. There are good parsers out there for just about any language. It
> > should be simple enough to get just the basic info out if you need it, while
> > alowing for others to push it's capabilities to the limit.
>
> > Also, having an RDF-based APML ontology opens up the possibility of
> > embedding attention profile information into HTML using RDFa.
>

[Paul Jones]

Hi Trent,

Sorry for being late chiming in on this issue - I was just observing the support, and still pondering my answer.

My major objective is to get us to a 1.0 specification, and I'd really like to avoid splintering the specification (and the effort) before we even reach that stage.

Beyond that, I do still hold big concerns about generating two separate APML specifications - this would likely cause substantial damage to user-perception, and having two different formats to interpret doubles the complexity of parsers; since regardless of counter-argument, a fully-compliant implementation would need to be able to read both to be of any use. 

I am still completely in support of adding RDF elements into the APML schema for 1.0, and having an officially endorsed transformation that makes it 100% compatible with SPARQL and other RDF tools. I don't really believe that we need to part schemas to do this - adding the metadata to the existing APML elements and simplifying the set to use a more metadata driven approach is something I've been considering (but sadly simply have not had the time to draft out).

My largest concern remains with two aspects of a completely RDF-styled solution. The first is readability. Whilst I know people will point out that computer readability is more important, the underlying format being readable assists in this. I, for instance, look at multiple APML files (and need to understand them) every single day. I also make heavy use of the Javascript transformation to make APML data available in web uis - something that a more abstract specification would likely reduce the utility of. Secondly, given that I have a system that processes substantial numbers of APML files, removing all metadata from the APML file in favour of simply using URIs makes working with these files quite a deal harder in my opinion. My ideal approach will be a balance between having both types of information in an APML file. (Perhaps utilising the Dublin Core schema as a source of standardised metadata that can be embedded for an element).

Thanks,

Paul

[David P. Novakovic]

My feeling here is that there are two basic opinions here. One is that
RDF is dangerously confusing and complex to end users, which goes
against all of the things APML was started to achieve. On the other
hand RDF provides far better integration options, especially in the
semweb world, arguably a completely different target market.

So we are stuck here where we are trying to use a single format to
please two crowds. The problem is, neither of them have mainstream
adoption yet. Appealing to the semweb crowd is not going to help
mainstream adoption any time soon, none of the companies represented
here will have any great influence on that.

We are not even at a v1 spec yet and we are voting on splintering the
community essentially. This is extremely dangerous and will cause more
damage to everyone, especially the commercial entities, than good.

This leads me to vote in support of Paul's idea, let's strengthen the
community and aim for widespread adoption, something we are all trying
to achieve. Using Paul's system will make the new APMl format easy to
integrate into your own systems Trent, and also give you the power to
provide RDF support where you need to use it. It gives the community a
simple format that can be easily sold to the wider web. RDF is a big
unknown to lots of people at this stage, APML has been hard enough to
explain to people, let alone trying to explain RDF at the same time.

Let's work together on adoption FIRST, then worry about complicating
the format later.

David

[Elias Bizannes]

For the record, I support RDF because of it is an enabler of the
semantic web. But I am also sensitive to practicality, and not being a
developer myself, don't think I can add my perspective because I don't
have experience implementing the spec.

So looking for a solution - could we perhaps consider the GRDDL work
that will enable the microformat-like pretty APML schema to transform
into a RDF junkie equivalent? The base spec would be XML, but there is
a way to easily transform the data into RDF if required.


On Sep 17, 10:19 am, "David P. Novakovic" <davidnovako...@gmail.com>
wrote:

> My feeling here is that there are two basic opinions here. One is that
> RDF is dangerously confusing and complex to end users, which goes
> against all of the things APML was started to achieve. On the other
> hand RDF provides far better integration options, especially in the
> semweb world, arguably a completely different target market.
>
> So we are stuck here where we are trying to use a single format to
> please two crowds. The problem is, neither of them have mainstream
> adoption yet. Appealing to the semweb crowd is not going to help
> mainstream adoption any time soon, none of the companies represented
> here will have any great influence on that.
>
> We are not even at a v1 spec yet and we are voting on splintering the
> community essentially. This is extremely dangerous and will cause more
> damage to everyone, especially the commercial entities, than good.
>
> This leads me to vote in support of Paul's idea, let's strengthen the
> community and aim for widespread adoption, something we are all trying
> to achieve. Using Paul's system will make the new APMl format easy to
> integrate into your own systems Trent, and also give you the power to
> provide RDF support where you need to use it. It gives the community a
> simple format that can be easily sold to the wider web. RDF is a big
> unknown to lots of people at this stage, APML has been hard enough to
> explain to people, let alone trying to explain RDF at the same time.
>
> Let's work together on adoption FIRST, then worry about complicating
> the format later.
>
> David
>

> > On Mon, Sep 15, 2008 at 4:24 PM, J. Trent Adams <jtrentad...@gmail.com>

[Paul Jones]

Hi Elias,

On Wed, Sep 17, 2008 at 11:59 AM, Elias Bizannes <elias.b...@gmail.com> wrote:

So looking for a solution - could we perhaps consider the GRDDL work
that will enable the microformat-like pretty APML schema to transform
into a RDF junkie equivalent? The base spec would be XML, but there is
a way to easily transform the data into RDF if required.

I have actually suggested this in the past, and it is actually the technical solution behind my remarks about having a "100% Endorsed Transform".

Paul.

[Daniel Renfer]

What about going the other way though? It may be easy enough to take
an APML document and get it into a format that can be read by RDF
parsers, but what about people that actually want to use APML in
conjunction with their RDF data.

APML seems like it would work really well with FOAF profiles, but
wouldn't using GRDDL be more of a one way transform?

[J. Trent Adams]

Paul and David -

I completely hear you and get where you're coming from with the desire
to keep APML as simple as possible.

Unfortunately, I've got a team of professional information retrieval
scientists (this is just to say they're not web dev folks learning
about this stuff as they go) who've shown me they can't accept APML
inbound as it currently stands. This is even with the introduction of
the RDF:about attribute (as it's primary utility is for
disambiguation, and not ontological identification without strict
namespaces and URI endpoints).

While you guys have clearly found utility with the format, however,
I'm not suggesting it should be abandoned. In fact, to illustrate the
fact that we're not giving up on serializing APML outbound for those
who can consume it (even though we can't), my company now allows it's
users to stream their MatchKeys in APML v.0.6 format. For example,
here's mine:

http://www.matchkey.com/streams/jtrentadams/public/APML

Further, we've been quoted as being committed to continuing to embrace
additional streaming formats:

http://www.thestandard.com/news/2008/09/15/matchmine-adds-openid-and-portability-matchkey

With that, my suggestion is (as distasteful as it sounds on the
surface) that I spend my time on an RDF version off to the side. This
would be with the eventual intent of rolling it back into APML when
the time's right. Perhaps that comes in a flavor GRDDL can leverage
as Elias and Daniel suggest. Even if we develop a mechanism to go
from a semantically-rich context into a more simple serialization,
we'll still need the hi-def solution at some point, so it won't be
wasted effort.

By developing this format off to the side of the current APML
mainline, we (hopefully) won't be adversely impacting the progress of
the KISS solution. If it turns out we're onto something, it'll become
obvious we should roll back into an APML-RDF version (or at least
translation) in the future. This should also help us each focus by
not continually debating which thread the group should pursue.

Toward a semantic future,
Trent


On Sep 16, 7:19 pm, "David P. Novakovic" <davidnovako...@gmail.com>
wrote:

> My feeling here is that there are two basic opinions here. One is that
> RDF is dangerously confusing and complex to end users, which goes
> against all of the things APML was started to achieve. On the other
> hand RDF provides far better integration options, especially in the
> semweb world, arguably a completely different target market.
>
> So we are stuck here where we are trying to use a single format to
> please two crowds. The problem is, neither of them have mainstream
> adoption yet. Appealing to the semweb crowd is not going to help
> mainstream adoption any time soon, none of the companies represented
> here will have any great influence on that.
>
> We are not even at a v1 spec yet and we are voting on splintering the
> community essentially. This is extremely dangerous and will cause more
> damage to everyone, especially the commercial entities, than good.
>
> This leads me to vote in support of Paul's idea, let's strengthen the
> community and aim for widespread adoption, something we are all trying
> to achieve. Using Paul's system will make the new APMl format easy to
> integrate into your own systems Trent, and also give you the power to
> provide RDF support where you need to use it. It gives the community a
> simple format that can be easily sold to the wider web. RDF is a big
> unknown to lots of people at this stage, APML has been hard enough to
> explain to people, let alone trying to explain RDF at the same time.
>
> Let's work together on adoption FIRST, then worry about complicating
> the format later.
>
> David
>

> > On Mon, Sep 15, 2008 at 4:24 PM, J. Trent Adams <jtrentad...@gmail.com>

[TSchultz55]

> APML seems like it would work really well with FOAF profiles, but
> wouldn't using GRDDL be more of a one way transform?

Dan, excellent point - this was one of the primary drivers, at least
for me personally, as to the benefits of an RDF format. Once you hook
your RDF attention profile into your FOAF file, you have the immediate
realization of object-centered sociality, in which connections between
people are intensified when a common object of interest becomes the
focal point.

Tim

On Sep 17, 9:07 am, "Daniel Renfer" <d...@kronkltd.net> wrote:
> What about going the other way though? It may be easy enough to take
> an APML document and get it into a format that can be read by RDF
> parsers, but what about people that actually want to use APML in
> conjunction with their RDF data.
>
> APML seems like it would work really well with FOAF profiles, but
> wouldn't using GRDDL be more of a one way transform?
>

> On Wed, Sep 17, 2008 at 7:07 AM, Paul Jones <pauljone...@gmail.com> wrote:
> > Hi Elias,
>

> > On Wed, Sep 17, 2008 at 11:59 AM, Elias Bizannes <elias.bizan...@gmail.com>

[cubicgarden]

+1 for me.