Re: Auxiliary proposal for passing MIME data through web intents

On Thu, Apr 26, 2012 at 7:06 AM, Greg Billock <gbillock@google.com> wrote:

> Apologies for the inaccessible working copies. I've just gone ahead
> and put them on the wiki now.
>
> Passing MIME type data through Web Intents :
>
> http://www.w3.org/wiki/WebIntents/MIME_Types
>
>
> And Passing schema.org type data through Web Intents :
>
> http://www.w3.org/wiki/WebIntents/schema.org_Types
>
>
> On Thu, Apr 26, 2012 at 2:43 AM, Robin Berjon <robin@berjon.com> wrote:
> > Hi Greg,
> >
> >> We talked about passing schema.org types as well. Here's a document
> >> spelling out how that would work (following the discussions we had at
> >> the Shenzhen F2F).
> >
> > Having thought and chatter about this some more, I don't think that we
> ought to specifically single-out schema.org. A type ought just to be a
> URL (hopefully with something at the end of it that can help you discover
> what the type is all about). But people should be able to mint the URLs
> they want.
>
> Correct. There's no implication that these are the only possible
> types; it's more an example of how to draw up such documents to show
> how to pass particular types in their own section of the type
> namespace.
>
> > For instance, if I built a distributed game system I might need a way to
> pick an orc. There doesn't seem to be a schema.org/Orc and I'm not sure I
> want there to be one.
>
> :-) Right. For such a case you'd make a new document about type
> definitions within http://berjon.com/game/ (suggest
> berjon.com/game/Spell :-))
>
> > Also, piggy-backing atop schema.org can be problematic when you have a
> good reason not to exactly match the data model that the type there
> requires. For example, the http://schema.org/Person type doesn't really
> match up all that well with the sort of information you'd find in an
> address book (it's rather strongly geared towards the sort of databases
> that news agencies keep about famous people, with a little bit of social
> networking pixie dust sprinkled over it). As a result I would expect
> (though this is just my opinion at this stage) that a Contact over Intents
> spec would use a type like http://w3.org/types/contact.
>
> Yes. If we end up with various specs built atop web intents, they'll
> need to document their types in a similar way. I've got a couple
> drafts in that direction, and if it's helpful, I can post those, too.
>
> > Note that I'm providing this feedback just based on the above cited
> paragraph and our discussion in Shenzhen — I haven't seen the documents you
> point to since they're inaccessible :)
>
> Thanks. I don't think the docs aim to exclude any other part of the
> namespace, just to define their own. I suppose the MIME one is
> different, in that there's only one MIME system. Certainly for
> microdata-style string literal types, we intend that to be the case.
> (Hence choosing the url namespace for types.)
>
> >> In general, these documents follow a form I'd like to see us follow
> >> for "type" string documentation -- detailing what you need to put
> >> where when invoking an intent with a given type, and what services can
> >> expect when they see those types.
> >>
> >> I'm not sure what format we want these in -- move them alongside the
> >> API spec? Put them on webintents.org? Put them on the w3 web intents
> >> wiki?
> >
> > I think it makes sense to document these on their own, standalone. I
> agree with timeless that making them productions of the TF makes sense.
> Note that if we also add some minimal microdata to describe types, we can
> also make them machine-discoverable.
>
> Yes! Making them rest in the same namespace and be compatible with
> microdata formats is an explicit goal. The schema.org doc I've drawn
> up doesn't give an explicit recipe for extracting microdata from a
> page, because that's part of the microdata and schema.org specs, but
> it should be clear that this is not just possible but desirable.
>

Then I think it would make sense to use the defined JSON serialization for
Microdata<http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#json>in
the hand-constructed example (top-level object with 'type' and
'properties' attributes, values as an array, etc.).

-jason


>
> >> timeless suggested [1] having these documents be productions of the
> >> task force. If that's a plan with broad agreement, should they go into
> >> mercurial? Respec formatted? Fill me in on the procedure, please, as
> >> well as the content of the documents.
> >
> > Feel free to use the repo you prefer so long as it's publicly available
> and supports documents just being seen on the Web. Inside the W3C
> infrastructure you can use CVS (if you really insist) or Mercurial, but
> some groups also use GitHub (using the gh-pages branch to publish the
> docs). It's up to you!
> >
> > As for ReSpec, if it's what you want to use then by all means go ahead
> (and as usual don't hesitate to bug me for support).
>
> Thanks. I've put them on the wiki for now. If there's agreement that
> they (or some descendent form) ought to be in Mercurial, I'll format
> them properly and stick them in.
>
> >
> > --
> > Robin Berjon - http://berjon.com/ - @robinberjon
> >
>
>