Back on the "URI things"

[gdupont]

I was thinking to something that may be a
good idea (or not !). The problem with URI is that actually most of
them are not "reliable" since nothing answer behind the URI. Very few
stable ontologies exist and thus the URI can perhaps be not usable.
Wikipedia and DBpedia seems to be quite large and reliable, but is it
enough ?

Moreover, sometimes users are interested in something new that has no
ever be describe in any existing knowledge base and thus no URI can be
define. But what if the terms used to describe it are ambiguous ?

So my proposal is that perhaps we can provide a place in the APML to
add RDF statements describing this kind of concepts that are not
described elsewhere... I know that we want to keep APML as simple as
possible. So, as URI, this must be an optional and only the semantic
aware and advanced applications will have to digg in RDF. Moreover, we
should find a way to keep the RDF part, as a part (less content than
in the APML itself).

Do the RDF addicts agree ? Do the "simple things" addicts have
specific objection ?

G.Dupont

[Paul Jones]

So I'm going to use this opportunity to advertise my desire for an extensions mechanism again. This definitely sounds to me like something that could be namespace imported into the APML.

If we have a standard "RDF-enhanced" extension to APML, then those applications that wish to provide these extra "assertions" about a given concept will be free to, and also have a standard mechanism for communicating them.

What do you think?

[gdupont]

Sounds good to me. But we should keep a simple but usable core to
avoid that all the work based on APML will be done through the
extension. Moreover extensions are subject to be more or less
proprietary (specified, implemented and used by a small group of
applications) and this should be limited. APML must be usable itself
and extra "whatever" should always still be optional (ie not
indispensable to use the others parts).

[Paul Jones]

Hi,

Sounds good to me. But we should keep a simple but usable core to
avoid that all the work based on APML will be done through the
extension. Moreover extensions are subject to be more or less
proprietary (specified, implemented and used by a small group of
applications) and this should be limited.

I'm not really sure I agree at this point. I'm basing my ideals for the extension process on the XMPP Extension Process (XEPs). If you look at any existing Jabber implementations, they often implement a plethora of different XEPs - but the fact they've standardised them means that when a certain piece of functionality is desired, it is always implemented the same way.

APML must be usable itself
and extra "whatever" should always still be optional (ie not
indispensable to use the others parts).

So I believe that "plain text" concepts is the usable core, and that additional semantic data is a good solid (standardised) extension.
 
Paul.

[Phil Barker]

Oh, I don't know. I'm new here, so please bear with me because I'm half
trying to learn what it is you're trying to do, and half trying to
contribute.

If you do want to put some description of a concept into the APML, then
the basic philosophy of RDF would be to reuse some existing vocabulary
where possible. That would be SKOS. But I do agree with your earlier
post that SKOS and zThes and the like are complementary to APML.

Anyway, a question: yes there are few stable ontologies(*) at the moment
to which URIs for concepts can refer. But, what you are suggesting would
only be usable by advanced semantic web type applications. Wouldn't such
applications require those ontologies in order to work?

I imagine that the scenario would be that any application generating
APML with URIs to identify concepts, would only do so if it had access
to an ontology to which it could refer with those URIs, and if it wanted
to refer to concepts not in that ontology would have a mechanism for
creating new entries (or at least identifiers for undefined entries).

Does that make any sense, or am I missing something?

Phil

(* actually there are lots of controlled vocabularies that would do, but
often they have usage restrictions, or are only used in certain
communities; and frequently they don't identify terms with URIs, but if
the maintainers of these vocabularies were a convinced that there was a
case for using URIs they could probably do so quite easily.)

[gdupont]

On Feb 15, 12:17 pm, "Paul Jones" <pauljone...@gmail.com> wrote:
> Hi,
>
> > Sounds good to me. But we should keep a simple but usable core to
> > avoid that all the work based on APML will be done through the
> > extension. Moreover extensions are subject to be more or less
> > proprietary (specified, implemented and used by a small group of
> > applications) and this should be limited.
>
> I'm not really sure I agree at this point. I'm basing my ideals for the
> extension process on the XMPP Extension Process (XEPs). If you look at any
> existing Jabber implementations, they often implement a plethora of
> different XEPs - but the fact they've standardised them means that when a
> certain piece of functionality is desired, it is always implemented the same
> way.
>

OK

> APML must be usable itself
>
> > and extra "whatever" should always still be optional (ie not
> > indispensable to use the others parts).
>
> So I believe that "plain text" concepts is the usable core, and that
> additional semantic data is a good solid (standardised) extension.
>

exactly !
> Paul.

[TSchultz55]

"If we have a standard "RDF-enhanced" extension to APML, then those
applications that wish to provide these extra "assertions" about a
given
concept will be free to, and also have a standard mechanism for
communicating them. "

Paul, could you give an example as to what this would look like if
implemented this way? Maybe I'm too stuck on the optional 'uri'
attribute concept......

Thanks!

Tim

On Feb 15, 5:37 am, "Paul Jones" <pauljone...@gmail.com> wrote:
> So I'm going to use this opportunity to advertise my desire for an
> extensions mechanism again. This definitely sounds to me like something that
> could be namespace imported into the APML.
>
> If we have a standard "RDF-enhanced" extension to APML, then those
> applications that wish to provide these extra "assertions" about a given
> concept will be free to, and also have a standard mechanism for
> communicating them.
>
> What do you think?
>

[Paul Jones]

Paul, could you give an example as to what this would look like if
implemented this way?  Maybe I'm too stuck on the optional 'uri'
attribute concept......

Bearing in mind here that my RDF isn't particularly strong (or even really existent at all), I've created something that I think might vaguely represent an APML 1.0 document with RDF extensions. I'd welcome someone with more OWL experience to tell me that I've used it all wrong, but I think this is what I'd be aiming for.

What does everyone thing?

<?xml version="1.0"?>

<APML xmlns="http://www.apml.org/apml-1.0" version="1.0" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:owl="http://www.w3.org/2002/07/owl">
  <Head>
    <Title>Example APML file for apml.org</Title>
    <Generator>Written by Hand</Generator>
    <Target type="http://www.apml.org/apml-1.0#target-email">sam...@apml.org</Target>
    <DateCreated>2007-03-11T01:55:00Z</DateCreated>
  </Head>
 
  <Body defaultprofile="Work">
    <Profile name="Home">
      <ImplicitData>
        <Concepts>
          <Concept key="attention" value="0.99" from="http://www.gatheringtool.com" updated="2007-03-11T01:55:00Z">
            <owl:sameAs rdf:resource="http://www.apml.org/objects#attention" />
          </Concept>
          <Concept key="content distribution" value="0.97" from="http://www.gatheringtool.com" updated="2007-03-11T01:55:00Z">
            <owl:differentFrom rdf:resource="http://en.wikipedia.org/wiki/Content_delivery" />
          </Concept>
        </Concepts>
        <Sources />
        <People />
        <Places />
      </ImplicitData>
      <ExplicitData>
        <Concepts />
        <Sources />
        <People />
        <Places />
      </ExplicitData>
    </Profile>
 
    <Profile name="Work">
      <ImplicitData />
      <ExplicitData>
        <Concepts />
        <Sources />
        <People />
        <Places />
      </ExplicitData>
    </Profile>

    <Applications>
      <Application name="sample.com" xmlns:sample="http://www.example.org/sample-app">
        <sample:SampleAppEl />
      </Application>
    </Applications>
  </Body>
</APML>

[TSchultz55]

Ok this is helpful to actually see these ideas in actual APML-form. I
see what you're saying now.

Here's my example so we can do a comparison of the two proposed
solutions:

#1:
<Concept key="wild turkey" value="1.00" from="http://

www.gatheringtool.com" updated="2007-03-11T01:55:00Z">

<owl:sameAs rdf:resource="http://tipplestore.shonky.co.uk/ontologies/
tipplestore-core.owl#Wild_Turkey" />
<owl:differentFrom rdf:resource="http://www.joesturkeyfarm.com/
products#Wild_Turkey" />
...
...
...
</Concept>

vs.

#2:
<Concept key="wild turkey" value="1.00" from="http://
www.gatheringtool.com" uri="http://tipplestore.shonky.co.uk/ontologies/
tipplestore-core.owl#Wild_Turkey" updated="2007-03-11T01:55:00Z"/>

I guess my feeling is that style #1 and style #2 basically achieve the
same results, with style #2 being less redundant and more "concise".
Yet style #1 allows you to append additional "knowledge" onto a
concept where style #2 does not (this is a huge selling point of
semantic web). Either way, all a semantic-enabled APML agent needs at
most is the specified resource and its corresponding ontology. From
there, all decisions made by an agent could be captured in a semantic
datastore such as Sesame for later use.

Diving into this OWL file specified by the 'uri' attribute, we see
that #Wild_Turkey rdfs:subClassOf #Kentuckey_Bourbon,
#Kentucky_Bourbon rdfs:subClassOf #Sour_Mash_Whiskey,
#Sour_Mash_Whiskey rdfs:subClassOf #Whiskies, and #Whiskies
rdfs:subClassOf #Spirits. Look at all the information we just
uncovered simply by specifying a single resource. Does style #1 we
really need the owl:differentFrom tag in this case? I would say not
simply because the agent has never made that connection in the first
place.

Then again maybe both of our examples are too simplified to actually
realize the benefits of style #1. Overall though both have their
pro's and con's....I'm just shooting for brevity and simplicity in
this case, as style #2 incites less overhead.

As always, thoughts are welcomed!

I can't believe I worked Wild Turkey into a technology discussion.

Happy Friday.

Tim

[Paul Jones]

I guess the other thing I didn't really attempt to hilight in my example is that you may want to list multiple facets - eg, defining a concept by saying it belongs to a set of categories of something similar. For example, I originally come from an Australian town called "Lismore". It turns out that Australia actually has two of these towns, but in different states. I can see me wanting to define that through a series of narrowing terms, and maybe even some negations.

I'm not entirely sure style #2 could do that, seeing as you've only got one attribute to use. I could be wrong though...

Paul.

[TSchultz55]

A URI should always point to a SPECIFIC identifiable thing or
concept.

Example: As you suggest, http://www.visitaustralia.org/locations#Lismore
is ambiguous by itself. There's two things that could be done to
clear up this confusion.

1.) The ontology could be refactored to something like
http://www.visitaustralia.org/locations#Lismore_West_Australia and
http://www.visitaustralia.org/locations#Lismore_East_Australia. (not
sure where the second Lismore is located....just guessing).

or

2.) Assume the ontology only contains information about ONE of the
'Lismore' towns and not the other. To confirm this, we'd have to look
in the document for something like #Lismore aus:locatedIn
#West_Australia. Once we find it, we now know that the #Lismore in
question is the one found in #West_Australia.

My point being given a single resource and a semantic datastore, you
should be able to traverse semantic relationship trees without having
to do any extra fancy "stuff".

Maybe we're on to something though in that making up "use cases" could
greatly benefit us in making decisions as to how to implement
semantics into APML?

Regards,

Tim

On Feb 15, 2:37 pm, "Paul Jones" <pauljone...@gmail.com> wrote:
> I guess the other thing I didn't really attempt to hilight in my example is
> that you may want to list multiple facets - eg, defining a concept by saying
> it belongs to a set of categories of something similar. For example, I
> originally come from an Australian town called "Lismore". It turns out that
> Australia actually has two of these towns, but in different states. I can
> see me wanting to define that through a series of narrowing terms, and maybe
> even some negations.
>
> I'm not entirely sure style #2 could do that, seeing as you've only got one
> attribute to use. I could be wrong though...
>
> Paul.
>

> On Fri, Feb 15, 2008 at 7:28 PM, TSchultz55 <TSchult...@gmail.com> wrote:
>
> > Ok this is helpful to actually see these ideas in actual APML-form. I
> > see what you're saying now.
>
> > Here's my example so we can do a comparison of the two proposed
> > solutions:
>
> > #1:
> > <Concept key="wild turkey" value="1.00" from="http://
> >www.gatheringtool.com" updated="2007-03-11T01:55:00Z">
> > <owl:sameAs rdf:resource="
> >http://tipplestore.shonky.co.uk/ontologies/

> > tipplestore-core.owl#Wild_Turkey<http://tipplestore.shonky.co.uk/ontologies/tipplestore-core.owl#Wild_...>"

> > />
> > <owl:differentFrom rdf:resource="http://www.joesturkeyfarm.com/

> > products#Wild_Turkey <http://www.joesturkeyfarm.com/products#Wild_Turkey>"

> > />
> > ...
> > ...
> > ...
> > </Concept>
>
> > vs.
>
> > #2:
> > <Concept key="wild turkey" value="1.00" from="http://
> >www.gatheringtool.com" uri="http://tipplestore.shonky.co.uk/ontologies/

> > tipplestore-core.owl#Wild_Turkey<http://tipplestore.shonky.co.uk/ontologies/tipplestore-core.owl#Wild_...>"

[Chris Saad]

Im fairly happy with everything being discussed there - I like the
idea that RDF and the concrete assertions are an extension to the core
spec and can be ignored by less sophisticated parsers. Really Simple
Attention is key.

We just need to be sure to choose either the Extension or the URI
Attribute - otherwise we might confuse the issue.

I will leave the specific implementation to you guys though.

Chris

On Feb 16, 6:56 am, TSchultz55 <TSchult...@gmail.com> wrote:
> A URI should always point to a SPECIFIC identifiable thing or
> concept.
>

> Example: As you suggest,http://www.visitaustralia.org/locations#Lismore

> is ambiguous by itself. There's two things that could be done to
> clear up this confusion.
>

> 1.) The ontology could be refactored to something likehttp://www.visitaustralia.org/locations#Lismore_West_Australiaandhttp://www.visitaustralia.org/locations#Lismore_East_Australia. (not

[Paul Jones]

So I had some thoughts about this overnight...

We just need to be sure to choose either the Extension or the URI
Attribute - otherwise we might confuse the issue.

I think so too. But if you see below, I think I've got a way to mix both!
 

On Feb 16, 6:56 am, TSchultz55 <TSchult...@gmail.com> wrote:
> A URI should always point to a SPECIFIC identifiable thing or
> concept.

As I say, my RDF isn't incredibly strong. I'd still wonder sometimes whether it would be useful to be able to use something like OWL when you want to provide more details over a single ontological item. And I guess you also have to consider the fact of just how much (or little) information the generator has.

How about we change the uri attribute to be instead "rdf:about". (Akin to using the about attribute on a rdf:description node). I think this opens the way to still use the OWL syntax within the node, but still provides for the simple non-verbose addition of an attribute to the primary node. I think it also helps it to be relatively self-documenting, since making it clear that it belongs within the RDF namespace makes it clear that it should be seen as an RDF-style semantic, and therefore URIs should be handled as such.

Cheers,
Paul.

[TSchultz55]

Paul,

Been at an off-site meeting all week....sorry for the delayed
response. In thinking about this, I like the rdf:about idea. It's
minimal and the namespace specifically denotes that this attribute
falls in the semantic space like you mentioned.

Think "Concept rdf:about #resource".

I would throw this idea on the roadmap. Does anyone else have any
thoughts?

> I'd still wonder sometimes whether
> it would be useful to be able to use something like OWL when you want to
> provide more details over a single ontological item.

I do like the concept, since this is where semantic web really shines
by being able to concatenate additional information about a resource.
I'll ponder some more on this.

Tim