Re: Auxiliary proposal for passing MIME data through web intents

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.

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

Received on Thursday, 26 April 2012 14:06:52 UTC