APML-RDF

[John Breslin]

Hi all -

I've been reading some of the related blog posts and mailing list
messages, and decided to try a first stab at an RDF ontology
corresponding to the APML specification.

It's version 0.01 because it is just the work of this afternoon, but I
need to look at a few (many) things off the top of my head (maybe Head
and Body could map to something else in RDF, and there are probably
more obvious subclass/subproperties that could be used to link APML
terms to FOAF, SKOS, DC, SIOC, etc.).

RDF schema:

http://rdfs.org/apml-rdf/ns

Picture so far:

http://apml.pbwiki.com/f/apml-rdf.png

Aims:

To provide links to a list of SIOC feeds that can serve as sources for
attention.

J.
--

[gdupont]

Good initiatives, I should have thought to this before. However, I'm
sure that the APML community is much involve into semantic because of
the apparent complexity of the language (for human). However, I see
many benefits to use RDF scheme like what you mentioned, especially
the link with FOAF. I'm particularly interested in that part because I
believe in the use of communities through APML profile of users that
have declared link together. I'll try to see what can be link to FOAF
tomorrow and hope that I can send something in that way.

cheers

gd

[TSchultz55]

gd,

While we're on the subject - did we ever reach a consensus as to how
we're going to embed concept semantics into the APML specification?

Your thread: http://groups.google.com/group/apml-public/browse_thread/thread/78a3452ec0d71edd
ended with Paul J. bringing up a good idea - last I saw of that convo.

Regards,

Tim

[gdupont]

The problem is that, as far as I know, there is no way to restrict a
XSD element to a specific XML syntax such as RDF without defining the
XSD complex types. I did not had time for that and thought that was
perhaps not the right way to do it.

My idea was to embed some RDF on the profile level in order to have a
local definition of tags (or keywords, or whatever you use in the
explicit/implicit keys) as it is done for the application definition.
In our internal work on data model we do such a thing (rdf embedded in
xml) to wrap RDF triples. Now we are thinking on moving all to
semantic by using RDFS instead of XSD... But a lot of tests have to be
done before that.

To go back on the subject, and on John's proposal, I will try to use
the rdf schema and see if it is too verbose or not.

gd

On Mar 31, 12:29 pm, TSchultz55 <TSchult...@gmail.com> wrote:
> gd,
>
> While we're on the subject - did we ever reach a consensus as to how
> we're going to embed concept semantics into the APML specification?
>

> Your thread: http://groups.google.com/group/apml-public/browse_thread/thread/78a34...

[scottw]

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.

[John Breslin]

Hi Scott -

Excellent - the reason being, I had thought that something like
AttentionProfileList or Document would be better for the body / head
stuff I had in the thrown-together-in-an-hour-or-two version and planned
that for the next iteration (great minds think alike, but thinking is
one thing, doing is another). However I thought it best to start with a
direct translation, and do away with the unneeded bits in the middle
along the way.

Does anyone else have any revisions or suggestions to Scott's proposal
below? BTW dc and dcterms have all merged now into dcterms so I would
also need to make that update to the spec.

I also need to see if we can subclass AttentionProfile and Concept /
Source to things like sioc:Container and sioc:Item, or to see if we can
link a sioc:User or foaf:Person to be the creator_of / maker of an
AttentionProfileDocument as well...

John.
--

--
Dr. John Breslin
DERI, NUI Galway
http://sw.deri.org/~jbreslin/
john.b...@deri.org

[gdupont]

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

[J. Trent Adams]

John, gd, and others -

In response to the question of companies planning to support APML, as
the Founder / Chief Innovator of matchmine [1], I've just announced
our commitment to the format as part of our broader initiative to
support the emerging DataPortability Project standards.

To that end, we're in the process of evaluating proposed modifications
to the existing APML spec that, IMO, would significantly enhance it's
utility. High on the list is embracing RDF for a variety of reasons
(many of which have been stated here). Not the least of which is
closer integration with the LD/SW communities (which are much closer
to being adopted today than when APML was first proposed).

I have a team of folks spinning up in my company to focus energy on a
formalized set of comments along those lines. In the meantime, I'll
raise my hand as a proponent of a bit more structure than what's in
the current APML spec.

Looking forward to it,
=jtrentadams

[1] http://www.matchmine.com/

[John Breslin]

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.
--

[David Novakovic]

APML v1 is going to break backwards compat. We might as well add these
things there.

David