- From: Greg Billock <gbillock@google.com>
- Date: Thu, 26 Apr 2012 07:06:16 -0700
- To: Robin Berjon <robin@berjon.com>
- Cc: WebIntents <public-web-intents@w3.org>
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