Re: Looking for a home for a proposed Credential Management API.
On 09/24/2014 09:57 AM, Mike West wrote: There's a credentials community group that has nothing to do with the proposal There's more in common than you might think. Fundamentally, the Credentials CG would like to ensure that the Credentials API that you're proposing supports the type of high-stakes, digitally signed credentials (like government-issued passports, professional licenses, background checks, etc.) that we need for the Web Payments work. I suggest reading up on what we'd like to see here: http://manu.sporny.org/2014/credential-based-login/ http://manu.sporny.org/2014/identity-credentials/ I'll do a review of your spec and use cases from a Credentials CG viewpoint. I'm happy to get on the phone w/ you and discuss things in more technical depth when you become available. That said, the right place to discuss the API is most likely Web Apps with input from WebCrypto WG, Security IG, Web Payments IG, FIDO Alliance, and the Credentials CG. I don't think you can do a good job on the API you're proposing without all of their involvement. and given the weak IPR protections of a CG, I'd prefer to avoid them in the long run (though they might be the right place for short-term incubation). I agree that the Credentials CG (or any CG) isn't the right place for the work in the long run. Keep in mind that the Web Payments work will most likely be starting soon, and they'll be in charge of recommending new WGs to be chartered to support the work. Transmitting credentials is a big part of the problem and a few modifications to your API could address that issue. Another option would be to create a new a new CG (although I suppose there could be some confusion with Manu's Credentials CG http://www.w3.org/community/credentials/). The Credentials CG can provide input, but most of the right people to talk about the API (and all of the potential security issues) probably exist in WebApps. As Robin said earlier in the thread, I wouldn't focus too much on the process and the right group too much. Get documents published, get implementations and polyfills done, then ping all of the groups listed above to get their feedback. The Credentials CG would be happy to provide input on the API as it relates to our use cases. -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: High-Stakes Credentials and Web Login http://manu.sporny.org/2014/identity-credentials/
Heads up: RDFa 1.1 headed into Last Call in January 2012
bcc: HTML WG, HTML Data Task Force, Web Apps WG, RDF WG, W3C TAG, SWCG, SVG WG, and PFWG This e-mail is to notify the liaison groups that are listed in the RDF Web Apps Working Group charter that the RDF Web Apps WG will be taking the RDFa 1.1 specs into what it hopes to be their final Last Call in January 2012. If you are so inclined, please take the time to do a review and submit your comments before January 15th 2012, which is the target date for entering Last Call for the RDFa 1.1 Primer, RDFa 1.1 Core, XHTML+RDFa 1.1 and RDFa 1.1 Lite. If it doesn't look like there are any major issues, we'll enter a 3-4 week Last Call period at that time and plan to move swiftly toward REC. Here are the links to the latest specs: RDFa Lite 1.1: http://www.w3.org/TR/2011/WD-rdfa-lite-20111208/ RDFa 1.1 Primer: http://www.w3.org/TR/2011/WD-rdfa-primer-20111208/ RDFa Core 1.1: http://www.w3.org/TR/2011/WD-rdfa-core-20111215/ XHTML+RDFa 1.1: http://www.w3.org/TR/2011/WD-xhtml-rdfa-20111215/ Happy Holidays! :) -- manu -- Manu Sporny (skype: msporny, twitter: manusporny) Founder/CEO - Digital Bazaar, Inc. blog: The Need for Data-Driven Standards http://manu.sporny.org/2011/data-driven-standards/
Request for Last Call review of RDFa Core 1.1
Hi WebAppers, The RDFa Working Group is making good progress on the RDFa API and hopes to have it into Last Call in the next couple of months. We intend to ask the Web Apps WG for an official review on the RDFa API before we enter LC. RDFa Core 1.1 and XHTML+RDFa 1.1 went into the Last Call during the past few weeks. The LC review period ends on December 6th, 2010, and December 9th 2010, respectively. In order to make sure that the review will be thorough, we would like WebApps to review RDFa Core 1.1, as it provides the basis for the RDFa API. If this group cannot perform a review before the LC end period, we'd be open to extending the review deadline for this group. Are there any volunteers for Last Call review of the RDFa Core 1.1 specification? http://www.w3.org/TR/2010/WD-rdfa-core-20101026/ Could you please mention the request for review during an upcoming telecon? I can be present on the call to ensure that the group understands the reason that we're asking for a review from this WG as well as answer any questions that the group may have on the RDFa WG's timeline. -- manu -- Manu Sporny (skype: msporny, twitter: manusporny) President/CEO - Digital Bazaar, Inc. blog: The Rising Swell of Web Application Data http://digitalbazaar.com/2010/10/30/json-ld/
Re: JSON-LD - Universal Linked Data markup for Web Services
On 05/31/2010 06:40 AM, Robin Berjon wrote:
I don't want to speak for this WG, and I'd rather we looked more
closely at technology before thinking about publication. I think we
ought to point out that rechartering WebApps isn't the easiest thing
ever, so that adding deliverables might prove tricky no matter what.
Understandable... never hurts to ask. :)
- This is an interesting project, but I don't think that you want to
set out with the goal of producing a replacement for SOAP.
Sorry, didn't mean to make it seem like it was a complete replacement
for SOAP. JSON-LD, combined with a number of other design patterns that
are starting to become standard on the web, could do something similar
to what SOAP was and is used for today.
You want
your goal to be something like the exchange of semantically rich
information using JSON that addresses the needs of a large segment of
the Web community. If it helps bring SOAP to the horrible death it so
dearly deserves, fine, but that's a side-effect.
Agreed.
- Your approach is built on the idea of encoding RDF or RDF-like
models into JSON. That has the downside of requiring people who
already have and use JSON-based exchange systems to change their
data.
Actually, it doesn't require developers to change their data. At least,
it doesn't require them to change immediately - they can do so at their
leisure. It's not clear in the spec right now, but all a Web Service
that consumes data needs to do to be JSON-LD compatible is declare a
default context. Therefore, if their input data was something like this
before:
{
IsMember : true,
Name : John,
Age : 24
}
Their service could define a default context like so:
{
a : Context,
IsMember : http://example.org/vocabs#member;,
Name : http://xmlns.com/foaf/0.1/name;,
Age : http://xmlns.com/foaf/0.1/age;,
ex : http://example.org/vocabs#;,
foaf : http://xmlns.com/foaf/0.1/;
}
So the data that they send up is the same as before, but it gets
automatically translated (at some point) to this:
{
http://example.org/vocabs#member; : true,
http://xmlns.com/foaf/0.1/name; : John,
http://xmlns.com/foaf/0.1/age; : 24
}
or they can mix/match:
{
IsMember : true,
foaf:name : John,
http://xmlns.com/foaf/0.1/age; : 24
}
or they can use the new markup:
{
ex:member : true,
foaf:name : John,
foaf:age : 24
}
All of these are valid in JSON-LD and they don't require the data source
to change their ways. The data consumer is the only one that needs to
change (and they would be the one that chooses to use JSON-LD).
Experience tends to show that that's rarely a very popular
option.
Which is why it was avoided :P
Have you considered taking a more GRDDL-like road and
providing a way to map existing JSON to a richer, more contextualised
semantic model?
I think that's the approach that was taken, right?
I'd
recommend taking a good look at JSON Schema in this context. Notably,
they've been adding ways of mapping simple values to links from the
schema, and those links can be typed (as in @rel). I haven't gone
through the motions, but I think that this gives you a lot of power
in mapping JSON to something RDFy.
I had looked at JSON Schema before, but not in this context. I looked at
it again and nothing popped to mind. I'll study it a bit more deeply the
next time I work on the JSON-LD specification.
Thanks for the input, Robin! It was very helpful in pointing out the
things that need to be explained in more detail in the spec. I need to
explain the you can continue to use the JSON that you've been using
concept more thoroughly.
-- manu
--
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.2.2 - Good Relations and Ditching Apache+PHP
http://blog.digitalbazaar.com/2010/05/06/bitmunk-3-2-2/2/
JSON-LD - Universal Linked Data markup for Web Services
Just in case there are people in this community that haven't seen this yet: On May 29th 2010, Manu Sporny tweeted: Just published JSON-LD: http://rdfa.digitalbazaar.com/specs/source/json-ld/ Universal markup of #rdfa #microdata and #microformats via lightweight JSON. #html5 #json #lod - Abstract Developers that embed structured data in their Web pages can choose among a number of languages such as RDFa, Microformats and Microdata. Each of these structured data languages, while incompatible at the syntax level, can be easily mapped to RDF. JSON has proven to be a highly useful object serialization and messaging replacement for SOAP. In an attempt to harmonize the representation of Link Data in JSON, this specification outlines a common JSON representation format for Linked Data that can be used to represent objects specified via RDFa, Microformats and Microdata. -- There is currently some discussion going on in the RDFa Community on this markup mechanism (start of thread): http://lists.w3.org/Archives/Public/public-rdfa/2010May/0018.html A great amount of effort was made to ensure that the markup mechanism was compatible with all existing adopted or REC-track structured data markup mechanisms - RDFa, Microformats and Microdata. Would this WG be amenable to publishing this spec as a FPWD (after about another month or two of work on it)? It deals with representing Web-wide objects between User Agents and Web Services. It is geared as a standards-based replacement of SOAP... REST + JSON-LD. Thoughts? -- manu -- Manu Sporny (skype: msporny, twitter: manusporny) President/CEO - Digital Bazaar, Inc. blog: Bitmunk 3.2.2 - Good Relations and Ditching Apache+PHP http://blog.digitalbazaar.com/2010/05/06/bitmunk-3-2-2/2/
Re: Quick review of RDFa DOM API?
, PlainLiteral, BlankNode, and TypedLiteral.
I can see why from the draft, but shortcuts would help. Or maybe it's
a library thing.
We hope to provide common shortcuts... we're actively working on
determining what those shortcuts should be.
- forEach: you can either define it as receiving just Function so
that it gets a function. That's fine, but it doesn't tell you what
that function is called with. The other option is to have it receive
a FooCallback object, which is in turn defined as an interface with a
single method that has the signature you expect, and has
[FunctionOnly, NoInterfaceObject].
You are right, we need to define that more clearly. Will do so in the
next rev.
- any reason why RDFTripleList wouldn't stringify to a list of
RDFTriples?
No reason. What we're grappling with is what the format of the list
should be. N3 or TURTLE? Or should it be a read-able string for developers?
- VERSION. Don't. API versioning doesn't work, in fact it doesn't
exist.
We'll strip this out of the next version of the RDFa DOM API.
- I'm not sure that I understand the value of the Convenient IRI
Mapping. The intent that I understand is to have:
rdfa.foo.bar # http://foo.com/ns#bar
rdfa.dahut.hunting # http://dahutsgalore.org/vocabularies/hunting
rdfa.dahut.unicorns # http://w3.org/2009/dap
It seems that the proposed solution is that you must first:
rdfa.setMapping(foo, bar, http://foo.com/ns#bar;);
rdfa.setMapping(dahut, hunting, http://dahutsgalore.org
/vocabularies/hunting);
rdfa.setMapping(dahut, unicorns, http://w3.org/2009/dap;);
What's the added value over:
var myMap = { foo: { bar: http://foo.com/ns#bar; },
dahut: { hunting: http://dahutsgalore.org
/vocabularies/hunting,
unicorns: http://w3.org/2009/dap; }};
?
Short answer - your solution is better (as long as developers aren't
required to type all of that out). We've come up with one that's better
still:
// This is really all you need
rdfa.setMapping(foo, http://foo.com/ns#;);
Then doing something like this:
rdfa.foo.bar
would automagically result in this:
IRI(http://foo.com/ns#bar;)
The getter for the foo IRI Mapping object would automatically append
any value attempted for retrieval by the getter to the end of the base
IRI and return that. So in this case, the base IRI is
http://foo.com/ns#; and the getter asked for the bar property, thus
the final IRI is: http://foo.com/ns#bar;
-- manu
--
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.2.2 - Good Relations and Ditching Apache+PHP
http://blog.digitalbazaar.com/2010/05/06/bitmunk-3-2-2/2/
