Turning the schema into a keyword registry rather than using URIs

8 views
Skip to first unread message

Martin Atkins

unread,
Jun 15, 2010, 4:12:55 PM6/15/10
to Activity Streams

Hi all,

Continuing the theme of simplification, I'd also like to explore the
idea of changing the verb and object type model to be a registry of
simple keywords rather than accepting URIs.

The specifics of how we'd manage such a registry remain to be
determined, though I suspect we would want registrants to fill in a
template somewhat like the schema descriptions in the core schema spec.
Other than requiring a description of how a new keyword is used I'd
expect that we'd set the bar pretty low to getting in the registry and
avoid creating a great deal of process around it.

It seems valuable to me to encourage people to innovate in a way that is
visible to the activity streams community at large, rather than going
off an creating private schemata that will not necessarily receive
peer-review or that will overlap with other work.

Keywords are also more readable and more straightforward to work with
than the URIs we have now; we already frequently drop the URI-ish bit
off the front of the identifiers for brevity during discourse, and
having that brevity in the serialization seems valuable too.

TypePad currently has experimental JSON-based activity streams
(undocumented and subject to change as the spec evolves) which show what
having singleton types that are just keywords looks like:
http://profile.typepad.com/markpasc/activity.json


Tatu Saloranta

unread,
Jun 15, 2010, 5:18:03 PM6/15/10
to activity...@googlegroups.com

For what it's worth, I have so far always considered value URIs as
just obscure long keywords. So system we have does produce and consume
them, but their usage is as opaque keys, to be converted to something
easier to consume.
In that regard it is fair question to ask whether such keys should be
overly long and opaque.

I am pretty sure that there would be ad hoc conventions for
namespacing, to use for custom types (company:person), which should
fulfill practical needs for collision avoidance. Perhaps spec could
recommend or specify such simple mechanism.

I like direction of simplifying things in cases where existing
complexity seems unwarranted, this seems like a good candidate for
further simplification.

-+ Tatu +-

Nathan

unread,
Jun 15, 2010, 5:24:48 PM6/15/10
to activity...@googlegroups.com
Tatu Saloranta wrote:
> On Tue, Jun 15, 2010 at 1:12 PM, Martin Atkins <ma...@degeneration.co.uk> wrote:
>> Hi all,
>>
>> Continuing the theme of simplification, I'd also like to explore the idea of
>> changing the verb and object type model to be a registry of simple keywords
>> rather than accepting URIs.
[SNIP]

> For what it's worth, I have so far always considered value URIs as
> just obscure long keywords.

keywords are human names, and very context specific.

URIs are machine names, and are globally unambiguous, by using a URI the
same 'thing' can be referenced both in and out of context and always be
unambiguous.

this is very old grass roots web principals here, if you want to shorten
it down to 'appear' like a keyword then simple use a default namespace.

Nathan

Tatu Saloranta

unread,
Jun 15, 2010, 6:50:23 PM6/15/10
to activity...@googlegroups.com
On Tue, Jun 15, 2010 at 2:24 PM, Nathan <nat...@webr3.org> wrote:
> Tatu Saloranta wrote:
...

> keywords are human names, and very context specific.

Keywords can be as long as necessary; but I guess your point is valid
in that value tokens probably should not be called keywords, since
that term has unintended connotations.
Shorter values in this case are by definition contextual, being values
for specific properties.
The main benefit of URIs is that of namespacing (there is no added
semantic information), it's just rather verbose way to do it.

> URIs are machine names, and are globally unambiguous, by using a URI the
> same 'thing' can be referenced both in and out of context and always be
> unambiguous.
>
> this is very old grass roots web principals here, if you want to shorten it
> down to 'appear' like a keyword then simple use a default namespace.

This has assumption of using XML. JSON does not have first-class
support for namespaces, so this is not applicable to JSON.
But even within XML this leads to rather unpleasant business of having
to mess with XML Schema, or added resolution of value types; unlike
with element and attribute names, namespace prefixes can not be
trivially expanded when they are uses for values.

This is not a huge issue per se; I just suspect that most users
effectively strip down anything before last slash and use that piece
as is; meaning most of URI is just an appendix to cut off.

-+ Tatu +-

Message has been deleted

Chris Messina

unread,
Jun 15, 2010, 10:08:04 PM6/15/10
to activity...@googlegroups.com
(Pardon the toppost.)

Two questions, one proposal.

1. Why don't we just indicate a default namespace, as someone else
mentioned, reserving the "short name" space for us?
2. Can't a namespaced URI just be considered a special kind of tag
that looks like a URL? It's just a unique token right? Or is there
some dereferenceability of namespaced URIs that make them special?

Proposal: since I'm all about simplifying whereever prudent, I like
the idea of simpler verbs and objects. What i don't like is the
potential for value collisions, especially where two words really can
mean different things, contextually ("check in" comes to mind).

So... we have two options to avoid collisions:

* use namespaced URIs (eww!)
* add an attribute to verb and object-type elements called "scheme"
which takes a root namespace URI as its value. Atom enthusiasts will
recognize this from the Atom category element, and has there already
been defined.

This way the data is generally simpler, but has the capability to be
more specific as situations warrant. This approach works less well
when we consider JSON serialization however, so I'd be interested to
hear Mart's thought on whether worrying about collisions is a more
likely real or imagined potential problem.

Chris

Sent from my iPhone 2G

On Jun 15, 2010, at 1:12 PM, Martin Atkins <ma...@degeneration.co.uk>
wrote:

>

> --
> You received this message because you are subscribed to the Google
> Groups "Activity Streams" group.
> To post to this group, send email to activity-
> str...@googlegroups.com.
> To unsubscribe from this group, send email to activity-strea...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/activity-streams?hl=en
> .
>

Martin Atkins

unread,
Jun 15, 2010, 10:45:15 PM6/15/10
to activity...@googlegroups.com
On 06/15/2010 07:08 PM, Chris Messina wrote:
> (Pardon the toppost.)
>
> Two questions, one proposal.
>
> 1. Why don't we just indicate a default namespace, as someone else
> mentioned, reserving the "short name" space for us?
> 2. Can't a namespaced URI just be considered a special kind of tag that
> looks like a URL? It's just a unique token right? Or is there some
> dereferenceability of namespaced URIs that make them special?
>

We could take the approach of saying that the keywords are assumed to be
prefixed with http://activitystrea.ms/1.0/schema/, but I would be
strongly against allowing that to appear in any serialization because
having two different ways to say the same thing will inevitably lead to
compatibility problems between implementations.

We certainly could say that these values can be a simple keyword OR a
URI, but I would cite the link relation namespace as prior art where the
ability to extend with URIs is almost always eschewed in practice;
instead, people just invent new ones and may or may not actually add
them to the IANA registry.

> Proposal: since I'm all about simplifying whereever prudent, I like the
> idea of simpler verbs and objects. What i don't like is the potential
> for value collisions, especially where two words really can mean
> different things, contextually ("check in" comes to mind).
>

The registry is intended to mitigate the collision problem by
encouraging people to share what they implemented so that others can
avoid conflict with it.

Joe Gregorio wrote a good article about distributed extensibility which
describes well the reasons why I'd like to make this change:
http://bitworking.org/news/2010/06/distributed-extensibility

>
> This way the data is generally simpler, but has the capability to be
> more specific as situations warrant. This approach works less well when
> we consider JSON serialization however, so I'd be interested to hear
> Mart's thought on whether worrying about collisions is a more likely
> real or imagined potential problem.
>

I think experience from Microformats and from link relations shows that
collisions between vocabularies are rarely a problem in practice and
that a centralized registry has benefits for interoperability and
collaboration.

Collisions in the English language can be reduced by choosing
descriptive rather than "cutesy", trendy words and by discussing
extensions in the open earlier rather than later. There are enough
synonyms in English that if there are two concepts that would naturally
have the same word we can probably find another word for one of them.


Monica Keller

unread,
Jun 16, 2010, 3:37:11 AM6/16/10
to Activity Streams, michel...@asemantics.com, dav...@asemantics.com
What do you guys think of describing verbs and object types using RDF.
Check out this spec
http://xmlns.notu.be/aair/
An RDF type template would be useful + some up to date information on
adoption.

I also like the idea of allowing several contributors to work
independently on extension specifications but register these with a
central organization like IANA. We could also publish status of the
spec and publishing and consuming. For now we should continue updating
the wiki describing all the properties needed for a certain object
type, examples in the wild and adoption. We have templates there.

As far as the namespace goes I am undecided. There are pros and cons
for both.

On Jun 15, 7:45 pm, Martin Atkins <m...@degeneration.co.uk> wrote:
> On 06/15/2010 07:08 PM, Chris Messina wrote:
>
> > (Pardon the toppost.)
>
> > Two questions, one proposal.
>
> > 1. Why don't we just indicate a default namespace, as someone else
> > mentioned, reserving the "short name" space for us?
> > 2. Can't a namespaced URI just be considered a special kind of tag that
> > looks like a URL? It's just a unique token right? Or is there some
> > dereferenceability of namespaced URIs that make them special?
>
> We could take the approach of saying that the keywords are assumed to be
> prefixed withhttp://activitystrea.ms/1.0/schema/, but I would be

Chris Messina

unread,
Jun 16, 2010, 3:29:56 PM6/16/10
to activity...@googlegroups.com, michel...@asemantics.com, dav...@asemantics.com

On Wed, Jun 16, 2010 at 12:37 AM, Monica Keller <monica...@gmail.com> wrote:
What do you guys think of describing verbs and object types using RDF.
Check out this spec
http://xmlns.notu.be/aair/
An RDF type template would be useful + some up to date information on
adoption.

Can you be more specific? What exactly would that look like — the spec you linked to does not look familiar to me, and therefore does not compute.
 

I also like the idea of allowing several contributors to work
independently on extension specifications but register these with a
central organization like IANA.

We would be the registry.
 
We could also publish status of the spec and publishing and consuming.

Not sure I understand what you mean by this?
 
For now we should continue updating
the wiki describing all the properties needed for a certain object
type, examples in the wild and adoption. We have templates there.

Yes.
 

As far as the namespace goes I am undecided. There are pros and cons
for both.

Joe Gregorio's arguments are compelling.

I'd rather actively maintain our schema and registry and drive value through our registry than see lots of non-interoperable implementations that don't talk to one another emerge.

Forcing people through a central point so that they *have to talk to one another* is not generally a bad thing.

Chris
 
--
You received this message because you are subscribed to the Google Groups "Activity Streams" group.
To post to this group, send email to activity...@googlegroups.com.

To unsubscribe from this group, send email to activity-strea...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/activity-streams?hl=en.




--
Chris Messina
Open Web Advocate, Google

Personal: http://factoryjoe.com
Follow me on Buzz: http://buzz.google.com/chrismessina
...or Twitter: http://twitter.com/chrismessina

This email is:   [ ] shareable    [X] ask first   [ ] private

Kevin Marks

unread,
Jun 16, 2010, 4:20:31 PM6/16/10
to activity...@googlegroups.com, michel...@asemantics.com, dav...@asemantics.com
Joe's arguments are very compelling, and the prior experience of microformats and the WhatWG rel's are good precedents for a Wiki as registry. Making stuff up is easy, agreement is hard, as we know, so having a place to list agreements and a small forcing function is a good thing.

That this can be remapped into an RDF vocabulary is a good thing too, for those who like RDF. Just as GRDDL did for making microformats into RDF, however, expecting people to understand RDF terminology to understand Activity Streams is likely to be limiting.

Martin Atkins

unread,
Jun 16, 2010, 4:31:12 PM6/16/10
to activity...@googlegroups.com
On 06/16/2010 01:20 PM, Kevin Marks wrote:
> Joe's arguments are very compelling, and the prior experience of
> microformats and the WhatWG rel's are good precedents for a Wiki as
> registry. Making stuff up is easy, agreement is hard, as we know, so
> having a place to list agreements and a small forcing function is a good
> thing.
>

Personally I think I'd rather have something a little more structured
than a wiki as a registry so that we can guide people to enter
information in a consistent form, but certainly something wiki-like
where anyone can sign in and hack on it and we have a revision history
on each record is exactly the kind of thing I was imagining as a
low-barrier mechanism for maintaining a registry.

Kevin Marks

unread,
Jun 16, 2010, 4:33:41 PM6/16/10
to activity...@googlegroups.com

Tatu Saloranta

unread,
Jun 17, 2010, 2:04:50 PM6/17/10
to activity...@googlegroups.com

Beyond reasonable arguments against having to do distributed
extensions, I think it is good to keep in mind that it's trivially
easy to still allow local custom types with naming conventions.
Anything from ensuring that official keywords do not contain a prefix
("prefix:verb", "prefix.verb" or whatever convention is chosen) to
capitalization (PNG uses 4-letter chunk headers, where standard types
have specific casing).
For public values registry absolutely makes sense. But even there one
could define different levels, given how much discussion and differing
opinions there are regarding whether to add certain values as
sanctioned ones ("dislike", "unjoin" and so forth).
In fact, using a prefix for non-canonical values might be nice for
readability: "proposed:unjoin" vs "join" vs "mycompany:unjoin".

I don't necessarily agree in that all value tokens (aka keywords) need
to be registered right away, or at all; just that this should be done
for public interfaces.

-+ Tatu +-

Chris Messina

unread,
Jun 17, 2010, 2:45:02 PM6/17/10
to activity...@googlegroups.com
Probably the most important thing that we need to develop next (after AtomActivity 1.0 is put to bed) is a process for developing the schema that is transparent, effective, lightweight, and encourage reuse and interop.

There's certainly prior art here — but I'd also like to reserve "graduating" new schema entries for verbs/object-types that have done the proper paperwork and have followed the process.

Perhaps if we plan to grow the index by — what? — 2-3 new types per month — we could keep momentum going without forcing massive dilution of the index?

Chris

--
You received this message because you are subscribed to the Google Groups "Activity Streams" group.
To post to this group, send email to activity...@googlegroups.com.
To unsubscribe from this group, send email to activity-strea...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/activity-streams?hl=en.

Martin Atkins

unread,
Jun 17, 2010, 2:55:46 PM6/17/10
to activity...@googlegroups.com
On 06/17/2010 11:45 AM, Chris Messina wrote:
>
> Perhaps if we plan to grow the index by � what? � 2-3 new types per
> month � we could keep momentum going without forcing massive dilution of
> the index?
>

I don't think it makes sense to measure progress by the number of things
in the schema or by the rate at which they are added.

We should aspire to have a small but capable schema. I think the measure
of success will actually be a *reduction* in how often we add things to
the schema. :)

Bill de hÓra

unread,
Jun 17, 2010, 3:56:36 PM6/17/10
to activity...@googlegroups.com
On 15/06/10 22:24, Nathan wrote:
> Tatu Saloranta wrote:
>> On Tue, Jun 15, 2010 at 1:12 PM, Martin Atkins
>> <ma...@degeneration.co.uk> wrote:
>>> Hi all,
>>>
>>> Continuing the theme of simplification, I'd also like to explore the
>>> idea of
>>> changing the verb and object type model to be a registry of simple
>>> keywords
>>> rather than accepting URIs.
> [SNIP]
>> For what it's worth, I have so far always considered value URIs as
>> just obscure long keywords.
>
> keywords are human names, and very context specific.
>
> URIs are machine names, and are globally unambiguous, by using a URI the
> same 'thing' can be referenced both in and out of context and always be
> unambiguous.

URIs are no less ambiguous than keywords. They are interchangeable in
the context of activity streams verb/objects referents.

> this is very old grass roots web principals here,

Martin's keyword idea will work as well as URIs if there is a governance
function for the registry. There's mo magic property that makes URIs
more or less ambiguous than keywords.

Bill

Dan Brickley

unread,
Jun 17, 2010, 4:24:19 PM6/17/10
to activity...@googlegroups.com, activity...@googlegroups.com

On 17 Jun 2010, at 21:56, Bill de hÓra <bi...@dehora.net> wrote:

>
>> this is very old grass roots web principals here,
>
> Martin's keyword idea will work as well as URIs if there is a
> governance function for the registry. There's mo magic property that
> makes URIs more or less ambiguous than keywords.

How about the relevant field being defined as taking URI values, but
permit relative URI references and define its fixed base URI to be a
link to the registry? Something of best of both worlds...

Dan

Chris Messina

unread,
Jun 17, 2010, 5:07:56 PM6/17/10
to activity...@googlegroups.com
I'm not opposed to that, but think it should be specified thus:

1. if no base URI is specified, presume http://activitystrea.ms/schema/1.0/ as the base.
2. where a base URI exists, concatenate the base UI + the type attributes to form the complete URI

Chris

 
Dan


--
You received this message because you are subscribed to the Google Groups "Activity Streams" group.
To post to this group, send email to activity...@googlegroups.com.
To unsubscribe from this group, send email to activity-strea...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/activity-streams?hl=en.

Martin Atkins

unread,
Jun 17, 2010, 5:24:52 PM6/17/10
to activity...@googlegroups.com
On 06/17/2010 01:24 PM, Dan Brickley wrote:
>
> How about the relevant field being defined as taking URI values, but
> permit relative URI references and define its fixed base URI to be a
> link to the registry? Something of best of both worlds...
>

I think it's unreasonable to expect implementers to use a URI resolver
to compare these things. They should just be able to do a
straightforward string comparison.

Even if we do define a base URI, I think I'd want the spec to prohibit
it from ever being used on the wire so that implementers don't need to
handle multiple different ways of saying the same keyword.

Chris Messina

unread,
Jun 17, 2010, 6:30:02 PM6/17/10
to activity...@googlegroups.com
Are you saying to just ignore the base namespace URI altogether and in all cases so that implementors will only look at the value of the given elements?

Chris
 





--
You received this message because you are subscribed to the Google Groups "Activity Streams" group.
To post to this group, send email to activity...@googlegroups.com.
To unsubscribe from this group, send email to activity-strea...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/activity-streams?hl=en.

Martin Atkins

unread,
Jun 17, 2010, 6:56:18 PM6/17/10
to activity...@googlegroups.com
On 06/17/2010 03:30 PM, Chris Messina wrote:
> On Thu, Jun 17, 2010 at 2:24 PM, Martin Atkins <ma...@degeneration.co.uk
> <mailto:ma...@degeneration.co.uk>> wrote:
>
> On 06/17/2010 01:24 PM, Dan Brickley wrote:
>
>
> How about the relevant field being defined as taking URI values, but
> permit relative URI references and define its fixed base URI to be a
> link to the registry? Something of best of both worlds...
>
>
> I think it's unreasonable to expect implementers to use a URI
> resolver to compare these things. They should just be able to do a
> straightforward string comparison.
>
> Even if we do define a base URI, I think I'd want the spec to
> prohibit it from ever being used on the wire so that implementers
> don't need to handle multiple different ways of saying the same keyword.
>
>
> Are you saying to just ignore the base namespace URI altogether and in
> all cases so that implementors will only look at the value of the given
> elements?
>

To be concrete, I want to be able to write (in Perl, since that's where
my brain is right now):

if ($type eq 'article')

not:

if ($type eq 'article'
|| $type eq 'http://activitystrea.ms/1.0/schema/article')

and definitely not:

use URI;
my $uri = URI->new_abs(
$type, "http://activitystrea.ms/1.0/schema/"
);
if ($uri->canonical eq 'http://activitystrea.ms/1.0/schema/article')


Chris Messina

unread,
Jun 17, 2010, 7:06:07 PM6/17/10
to activity...@googlegroups.com
Right, so you're arguing for NO support for namespaces — base URIs or not.

That's not to say that a valid verb/object-type couldn't be "http://mywebsite.com/schema/checkin", but that it would be treated as an opaque string, rather than a dereferenceable URI.

Ok, I could live with that.

Chris

Martin Atkins

unread,
Jun 17, 2010, 7:11:09 PM6/17/10
to activity...@googlegroups.com
On 06/17/2010 04:06 PM, Chris Messina wrote:
>
> Right, so you're arguing for NO support for namespaces � base URIs or not.

>
> That's not to say that a valid verb/object-type couldn't be
> "http://mywebsite.com/schema/checkin", but that it would be treated as
> an opaque string, rather than a dereferenceable URI.
>
> Ok, I could live with that.
>

Right. As long as the comparison method is basic string comparison (and,
ideally, the tokens would contain only ASCII characters) and doesn't
require any URI normalization.

But at that point, I don't really see the point in using URIs. We might
as well just use prefixed strings like mywebsite:foo or
com.mywebsite.foo to make it obvious that these things MUST NOT be
treated as if they were URIs.

Personally I'm not a fan of the Java-ish reverse DNS scheme for
aesthetic reasons, but I don't feel that strongly about it.

Chris Messina

unread,
Jun 17, 2010, 8:08:07 PM6/17/10
to activity...@googlegroups.com
On Thu, Jun 17, 2010 at 4:11 PM, Martin Atkins <ma...@degeneration.co.uk> wrote:
On 06/17/2010 04:06 PM, Chris Messina wrote:

Right, so you're arguing for NO support for namespaces — base URIs or not.


That's not to say that a valid verb/object-type couldn't be
"http://mywebsite.com/schema/checkin", but that it would be treated as
an opaque string, rather than a dereferenceable URI.

Ok, I could live with that.

Right. As long as the comparison method is basic string comparison (and, ideally, the tokens would contain only ASCII characters) and doesn't require any URI normalization.

But at that point, I don't really see the point in using URIs. We might as well just use prefixed strings like mywebsite:foo or com.mywebsite.foo to make it obvious that these things MUST NOT be treated as if they were URIs.

Personally I'm not a fan of the Java-ish reverse DNS scheme for aesthetic reasons, but I don't feel that strongly about it.

I think the most important thing that needs to happen, then, with this approach is what we tell people who want to launch something but that don't want to use our process for adding their new item to the registry... for example, say Company X comes along with 40 new verbs and 50 new objects and just injects them into their feed... should they use "companyx:newverb" or a URL-looking string ("http://companyx.com/schema/newverb")?

What is our guidance for groups that want to extend, but for whom the conditions aren't met to be added to the registry?

Monica Keller

unread,
Jun 17, 2010, 10:15:41 PM6/17/10
to activity...@googlegroups.com
I do agree that URLs look odd in JSON and people really expect names or labels

I advocate for the verb and object types to remain as case sensitive strings and not become enums.

By doing this we allow

1- Implementers to serialize the activity and use new object types if they need to, obviously they should reuse if possible existing ones.
2- Independently decide if they want to register their object type or verb as something that would be useful for others and go through the process.

One more proposal:
We could add properties "verb_ns" and object_type_ns" and have them default to "http://activitystrea.ms/schema/1.0/ " or
"verb_registry" and "object_type_registry" and have it default to "activitystreams"


--

Angel Robert Marquez

unread,
Jun 17, 2010, 11:28:06 PM6/17/10
to activity...@googlegroups.com

Angel Robert Marquez

unread,
Jun 17, 2010, 11:37:43 PM6/17/10
to activity...@googlegroups.com

Martin Atkins

unread,
Jun 18, 2010, 11:20:46 AM6/18/10
to activity...@googlegroups.com
On 06/17/2010 07:15 PM, Monica Keller wrote:
> I do agree that URLs look odd in JSON and people really expect names or
> labels
>
> I advocate for the verb and object types to remain as case sensitive
> strings and not become enums.
>
> By doing this we allow
>
> 1- Implementers to serialize the activity and use new object types if
> they need to, obviously they should reuse if possible existing ones.
> 2- Independently decide if they want to register their object type or
> verb as something that would be useful for others and go through the
> process.
>
> One more proposal:
> We could add properties "verb_ns" and object_type_ns" and have them
> default to "http://activitystrea.ms/schema/1.0/ " or
> "verb_registry" and "object_type_registry" and have it default to
> "activitystreams"
>

To continue the previous theme:

$type_ns = "http://activitystrea.ms/schema/1.0/" if ! defined($type_ns);
if ($type eq 'article'
&& $type_ns eq "http://activitystrea.ms/schema/1.0/")

Not really sure what value this additional complexity provides. People
are just going to get it wrong and then be surprised when they encounter
something like:
"objectTypeNS": "http://example.com/",
"objectType": "article"

Chris Messina

unread,
Jun 18, 2010, 8:00:36 PM6/18/10
to Activity Streams
I've gone ahead and written up the outcomes (as I perceive them) on
the wiki:

http://wiki.activitystrea.ms/Namespaces

Please take a look and provide feedback and/or edits.

I think it captures the decisions we made in this thread, though it
might not be complete on our rationale.

Chris

On Jun 17, 7:15 pm, Monica Keller <monica.kel...@gmail.com> wrote:
>  I do agree that URLs look odd in JSON and people really expect names or
> labels
>
> I advocate for the verb and object types to remain as case sensitive strings
> and not become enums.
>
> By doing this we allow
>
> 1- Implementers to serialize the activity and use new object types if they
> need to, obviously they should reuse if possible existing ones.
> 2- Independently decide if they want to register their object type or verb
> as something that would be useful for others and go through the process.
>
> One more proposal:
> We could add properties "verb_ns" and object_type_ns" and have them default
> to "http://activitystrea.ms/schema/1.0/" or
> "verb_registry" and "object_type_registry" and have it default to
> "activitystreams"
>
> On Thu, Jun 17, 2010 at 5:08 PM, Chris Messina <chris.mess...@gmail.com>wrote:
> > activity-strea...@googlegroups.com<activity-streams%2Bunsubscrib e...@googlegroups.com>
> > .

John Panzer

unread,
Jun 18, 2010, 8:36:57 PM6/18/10
to activity...@googlegroups.com
SGTM!
--
John Panzer / Google
jpa...@google.com / abstractioneer.org / @jpanzer

> To unsubscribe from this group, send email to activity-strea...@googlegroups.com.

Monica Keller

unread,
Jun 19, 2010, 12:36:38 AM6/19/10
to activity...@googlegroups.com, Activity Streams
I like for the most part, but we should not assume that company x's
will always do URIs

We should also test this central registry repo idea with some actual
implementors before making it official

Please everyone keep updating the wiki

On Jun 18, 2010, at 5:00 PM, Chris Messina <chris....@gmail.com>
wrote:

> I've gone ahead and written up the outcomes (as I perceive them) on

> To post to this group, send email to activity-
> str...@googlegroups.com.


> To unsubscribe from this group, send email to activity-strea...@googlegroups.com

Monica Keller

unread,
Jun 19, 2010, 1:29:11 AM6/19/10
to activity...@googlegroups.com
In more detail:

I think we are all in favor of non URI verbs and object types and we should not recommend it for anyone.

I am not married to having an option for expressing the registry in addition to the objectType/verb but it does give us more obvious extensibility than having a single field. I would probably use associative arrays indexed by the registry first and encourage people releasing extensions. Ours would of course be the default.

So on Chris's update on the wiki page I think we need to clarify that anyone can use the short form. Ex: "study"  and not "http://www.school.edu/study" because once they become standardized they will not need to release a new version of their api. The implementors should be aware that if they use a short form objectType or verb and never submit it for standardization they run the risk of bieng trampled by the official implementation or even someone else's private implementation so its in their best interest

Chris can you update this or should I ?

>So, if Company X wants to create its own set of verbs and objects without following the ActivityStreams Process (thus without worrying about interoperability) they can still use the fundamental format and serialization of ActivityStreams, but with their own verbs and object-types, ideally in a form like this: 

 



Right, so you're arguing for NO support for namespaces — base URIs or
not.

.
For more options, visit this group at
http://groups.google.com/group/activity-streams?hl=en.

--
You received this message because you are subscribed to the Google Groups "Activity Streams" group.
To post to this group, send email to activity...@googlegroups.com.
To unsubscribe from this group, send email to activity-strea...@googlegroups.com.

Chris Messina

unread,
Jun 19, 2010, 1:31:49 AM6/19/10
to activity...@googlegroups.com
Sure, but it doesn't really matter if some random company doesn't use
URL-like strings -- they just won't interoperate with anyone else. And
if they try to reuse an existing registered token/word, it'll just
confuse parsers.

Ultimately there's little value in branching off from the registry,
and it should be understood that we can't prevent that. We also can't
force parsers to support stuff that doesn't make sense. ;)

Sent from my iPhone 2G

On Jun 18, 2010, at 9:36 PM, Monica Keller <monica...@gmail.com>
wrote:

> I like for the most part, but we should not assume that company x's

Monica Keller

unread,
Jun 19, 2010, 1:58:36 AM6/19/10
to activity...@googlegroups.com
I am not advocating for random companies doing one offs. 

I am just being realistic about publishers sometimes wanting to release apis including an activity stream api and not wanting to wait until Martin, Rob, Will, you and me(not sure who is on this registrar) approve their nomeclature. They may have wikid it but its not approved yet.

As far as parser go they would handle it as a typeless object and a post just like with atom.


Right, so you're arguing for NO support for namespaces — base URIs or
not.

.
For more options, visit this group at
http://groups.google.com/group/activity-streams?hl=en.

--
You received this message because you are subscribed to the Google Groups "Activity Streams" group.
To post to this group, send email to activity...@googlegroups.com.
To unsubscribe from this group, send email to activity-strea...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/activity-streams?hl=en.


--
You received this message because you are subscribed to the Google Groups "Activity Streams" group.
To post to this group, send email to activity...@googlegroups.com.
To unsubscribe from this group, send email to activity-strea...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/activity-streams?hl=en.


--
You received this message because you are subscribed to the Google Groups "Activity Streams" group.
To post to this group, send email to activity...@googlegroups.com.
To unsubscribe from this group, send email to activity-strea...@googlegroups.com.

Dan Brickley

unread,
Jun 19, 2010, 3:14:23 AM6/19/10