The minutes from today's call are now available here:
http://json-ld.org/minutes/2012-08-14/
Full text of the discussion follows including a link to the audio
transcript:
--------------------
JSON-LD Community Group Telecon Minutes for 2012-08-14
Agenda:
http://lists.w3.org/Archives/Public/public-linked-json/2012Aug/0011.html
Topics:
1. JSON-LD at NoSQL conference
2. In-memory JSON-LD object representation
3. @language / @vocab Intransitivity
4. ISSUE-80: Remove initial context from API spec
5. ISSUE-150: Use of native types in from/to RDF
6. ISSUE-151: Context Processing Algorithm Dependency
Resolution
Resolutions:
1. Do not support an initial context in JSON-LD 1.0.
2. Continue to support 'useNativeDatatypes' in .fromRDF(),
specifying how the native type conversion happens. Do not support
options for overriding each native datatype with a different
value.
Action Items:
1. Dave Longley to send suggested spec text to modify the
algorithm to public-rdf-comments@w3.org
Chair:
Manu Sporny
Scribe:
Manu Sporny
Present:
Manu Sporny, Gregg Kellogg, Niklas Lindström, Markus Lanthaler,
Dave Longley
Audio:
http://json-ld.org/minutes/2012-08-14/audio.ogg
Manu Sporny is scribing.
Manu Sporny: Anything else that needs to be on the agenda?
Topic: JSON-LD at NoSQL conference
Gregg Kellogg: I'm talking at the NoSQL conference, please
review my slides.
Manu Sporny: What's the strategy with this talk?
Gregg Kellogg: Stay away from the algorithms, introducing the
concepts - expanded form / compacted form - discussion on how to
get to compacted form. Benefits between expanded and compacted
form.
Gregg Kellogg: Integration w/ JSON-LD w/ databases like MongoDB
or CouchDB - use references, use object-level granularity,
graphify() vs. other approaches to working with the data.
Gregg Kellogg: Tying into backbone.js - trying to retrieve from
DB, map to model (backbone), and display. Mostly practical
experience and how to use JSON-LD in production code.
Gregg Kellogg: I've built a serialization of schema.org and
other stuff into JSON-LD serialization... which feeds Backbone
application that gives cool documentation for all of the API
points - used constraints quite a bit to give more structure.
Also built an object editor - object model defined by schema...
helps create/edit/validate all object instances, which are then
stores in MongoDB collection.
Gregg Kellogg: Any app built on any schema, very useful.
Manu Sporny: Would you be able to put it out as open source at
some point?
Gregg Kellogg: I think so.
Gregg Kellogg: Did lots of the backend in CoffeeScript.
Niklas Lindström: Yeah, CoffeeScript is nice... also use
JavaScript. Nicer to work in CoffeeScript.
Topic: In-memory JSON-LD object representation
Gregg Kellogg: This type of application shows the advantages of
Linked Data models... I think I'd like .link() instead of
.graphify() because that's what you're really doing here.
Gregg Kellogg: When I edit a specific object, I can do a query
to get back any object that has a relationship to a particular
object... then tie them together using .link() - pretty useful
term for what I'm doing.
Niklas Lindström: I use .connect() in my RDFa experiment.
Niklas Lindström: In my RDF lab - simple idea - a schema
vocabulary presentation and then some kind of editor. Did this
years ago, but would like to try it out w/ JSON-LD approach.
Niklas Lindström:
http://niklasl.github.com/rdfa-lab/examples/rdfa-dom-usage
Niklas Lindström: I use an HTML5 data-* attribute to store the
expanded version of the RDFa data...
Niklas Lindström: I go from RDFa to JSON-LD directly...
Niklas Lindström: I'll eventually put all of this up on the wiki
- real goal of this experiment is to put more of the parser logic
into the DOM API to eventually be able to produce JSON-LD from
the DOM API.
Niklas Lindström: I think it'll be pretty small amount of
JavaScript.
Niklas Lindström: Trying to find a balance between logic needed
to extract @context from DOM and what the current term
represents.
Niklas Lindström: If it has a subject that comes from a subject
element, these things can be put together simply w/o extracting
triples... conversion to JSON-LD should be easy.
Niklas Lindström: The goal of the DOM API is to navigate through
the DOM using RDF concepts.
Manu Sporny: Yes, that's good - extracting JSON-LD is very good.
Niklas Lindström: The Microdata API actually gives you back
elements carrying the properties, then if you do .toJSON() you
get the JSON representation at that point. It dawned on me that
that may be the way forward for the DOM API. You want to be able
to navigate the HTML elements using RDFsubjects/objects/ etc.
Manu Sporny: Ok, anything else to add to the Agenda before we
start?
Topic: @language / @vocab Intransitivity
Niklas Lindström: It might make sense to make @vocab and
@language intransitive? If you inherit a context from another
context, you don't necessarily inherit the @language. If you have
a @context which sets the language, you don't see that. Maybe the
closest context should affect the language.
Manu Sporny: my concern is that it complicates things (@language
acts differently in different places) and prevents certain things
from working (like being able to set @language in @context).
Niklas Lindström: Is @vocab in there now?
Gregg Kellogg: Yes, it's in there now, Markus added it.
Gregg Kellogg: Also, there is now spec text for a more formal
description of JSON-LD...
Manu Sporny: Yes, haven't had a chance to look at it yet, hope
to do so tsoon.
Gregg Kellogg: I haven't pinged Andy Seaborne on it yet...
Manu Sporny: Yes, we need to publish a new Working Draft via RDF
WG as well - we should do it soon.
Niklas Lindström: https://github.com/RDFLib/rdflib-jsonld
Niklas Lindström: I updated the JSON-LD implementation for
rdflib.
Topic: ISSUE-80: Remove initial context from API spec
https://github.com/json-ld/json-ld.org/issues/80
Manu Sporny: I think we left it at: Gregg and me wanting to put
it in the spec, Markus and Niklas not wanting to put it into the
spec.
Niklas Lindström: It might be nice to have xsd and rdf
pre-defined..
Gregg Kellogg: Maybe schema as well?
Gregg Kellogg: I end up setting @vocab to "http://schema.org/"
for most of what we're doing.
Niklas Lindström: I don't think we should do that (set @vocab to
schema.org)
Manu Sporny: It might be helpful to have pre-defined terms, but
it might also make it more difficult to understand JSON-LD
Niklas Lindström: We might want to "level the ground" to not
have implicit prefixes... if we decide to have an initial
context, it should be able to completely cancel it by setting
"@context": [null, x, y z]
Gregg Kellogg: I rarely use "rdf" namespace in JSON-LD. One
advantage of JSON-LD is that there is support for datatypes. If
you do any support for datatypes, you need "xsd". I continue to
forget to include it and I have to go and look up the URI.
Gregg Kellogg: I think that having "xsd" as a pre-defined term
in the initial context would be very useful, avoid many easy
mistakes.
Markus Lanthaler: You don't really use "xsd" that often...
mostly for dates.
Gregg Kellogg: I also use it for owl serialization stuff - most
of the cardinality stuff are unsigned integers.
Gregg Kellogg: You have to declare something - not a typical
usage pattern.
Niklas Lindström: schema.org have defined their own datatypes,
which are basically string-derived.
Gregg Kellogg: OWL definition they have they end up being object
properties - it's not very useful. rdfs.org version is much
better in that regard, doesn't contain as much ranging
information.
Gregg Kellogg: Interesting to note that you can't really do this
modeling round-tripping in Microdata.
Niklas Lindström: Take a look at the RDFa representation, they
don't use rdfs:range and rdfs:domain... they use schema:range and
schema:domain.
Markus Lanthaler: This is convenient - but I don't think
prefixes are one of the "good" features of JSON-LD.
Markus Lanthaler: I think that w/o prefixes, they don't have
value for you - and they may clash.
Niklas Lindström: I think that if we add prefixes - anything
used as a prefix cannot be used as a default term unless you
reset it, they will collide.
Niklas Lindström: Maybe we discussed this before - possibility
of defining a term w/ a trailing colon to mean "only use this as
a prefix, never a term".
Markus Lanthaler: Argument against that is "no microsyntaxes"
Niklas Lindström: There was a collision which would be
preventable w/o the term. I defined a thing to use as a prefix
locally, to make term declarations simpler/more compact.
Niklas Lindström: The problem was that I did not want the prefix
to be used later on in general, it ended up somewhere I wanted to
use it.
Gregg Kellogg: I do use prefixes a lot, mostly in context
definition.
Gregg Kellogg: Within data, I rely on terms for things I
explicitly use in my code. When I do things to work w/ more
generic data, terms/curies don't impact me at all. When working
with multiple vocabs, better to keep things in a CURIE syntax.
Gregg Kellogg: Translation from TURTLE is more natural when
using CURIEs as long as you have access to prefix definitions.
Markus Lanthaler: In that case, there is no danger for
forgetting declaration - comes from TURTLE.
Gregg Kellogg: I was responding to "CURIEs not very useful"
statement.
Gregg Kellogg: I think the only one that needs to be in there is
XSD.
Manu Sporny: I think I don't want an initial context in there
now... you only need "xsd" when you are declaring contexts, you
don't do that that often.
Manu Sporny: If we really need to put this feature in, then we
can do so in the implementations later on.
Gregg Kellogg: At this point, I don't feel strongly enough to
object to not having it. My feeling is that it does more good
than harm... but I'll just do a -0 on a resolution.
PROPOSAL: Do not support an initial context in JSON-LD 1.0.
Manu Sporny: +1
Niklas Lindström: +0.75
Markus Lanthaler: +1
Gregg Kellogg: -0
RESOLUTION: Do not support an initial context in JSON-LD 1.0.
Topic: ISSUE-150: Use of native types in from/to RDF
https://github.com/json-ld/json-ld.org/issues/150
Markus Lanthaler: before we decided to have a "useNativeTypes"
flag in the fromRDF() algorithm, it automatically assumes we're
using "xsd:boolean", "xsd:double", etc.
Markus Lanthaler: Dave Longley proposed to split that flag into
4 different flags that specify the datatype for each of the
native types... one flag for integers (maps by default
toxsd:integer), and so on.
Markus Lanthaler: The question is whether or not we want to do
that.
Gregg Kellogg: It's been several months since this came up - but
adding flags to the RDF serialization makes it a little bit
crufty and unwieldy. I'd rather come up with a set of practices
that are just constrained to the RDF serialization. Let's just
fix these things, if you're transforming an integer fromRDF() to
RDF, you can represent it fairly easily in TURTLE (as an
integer).
Markus Lanthaler: The question is in the other direction - if
you're doing fromRDF() and you want to convert "unsigned
integers" to "integers", then you would want to do this.
Gregg Kellogg: I don't find the value to represent this as a
non-negative integer as something else.
Manu Sporny: My concern is that we're closing off some use case
by not allowing this to happen.
Gregg Kellogg: If everything I was doing was using the JSON-LD
API, then everything I was doing through the API calls...
Gregg Kellogg: I have an RDF distiller, it hasn't needed any
special attributes for any particular serialization.
Gregg Kellogg: I think that my serializes for TURTLE do not make
use of the native representation for these things by default.
There might be some tools, but I use string representations for
things.
Markus Lanthaler: I think the question is if we want to decouple
JSON-LD from XSD. For example, schema.org uses their own
datatypes.
Manu Sporny: Two arguments here - complexity vs. flexibility
Gregg Kellogg: Going from RDF to JSON-LD, that's a different
issue - we don't make use of native datatypes when transforming
from RDF to JSON-LD.
Manu Sporny: My concern is that JavaScript developers expect
stuff to be converted to native types.
Niklas Lindström: I see cases for both sides of this argument. I
mainly agree with Gregg - there is a standard way to say what
types are in RDF.
Gregg Kellogg: I might provide some interfaces to provide
greater fidelity. I'd put a flag in there that says "use native
datatype representations".
Gregg Kellogg: We could say that "implementations may provide a
mechanism that allows these representations to be overridden."
Manu Sporny: Okay - so we could just keep 'useNativeDatatypes',
specify how to do the conversion, and add this feature in later.
Markus Lanthaler:
http://json-ld.org/spec/latest/json-ld-api/#jsonldoptions
PROPOSAL: Continue to support 'useNativeDatatypes' in
.fromRDF(), specifying how the native type conversion happens. Do
not support options for overriding each native datatype with a
different value.
Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
Markus Lanthaler: +1
RESOLUTION: Continue to support 'useNativeDatatypes' in
.fromRDF(), specifying how the native type conversion happens. Do
not support options for overriding each native datatype with a
different value.
NOTE: If this feature needs to be added in the future, it can be
done without creating any backwards-compatability issues.
Topic: ISSUE-151: Context Processing Algorithm Dependency Resolution
https://github.com/json-ld/json-ld.org/issues/151
Manu Sporny: The main issue is this, if you define something
like so in the @context: "schema": "http://schema.org/"
Manu Sporny: and then later you do this: "name": "schema:name"
Manu Sporny: Dave Longley is concerned that there are some
corner cases that could lead to implementations doing two
different things.
Gregg Kellogg: I'm concerned that we don't need to spec
everything down to this level of details. Oddly construed
examples could be placed into the test suite - that could catch
these implementation issues.
Gregg Kellogg: This sounds like an error condition that we want
to signal, not that everyone can resolve this stuff in the same
way.
Markus Lanthaler: It's difficult to understand what the
algorithms are supposed to do w/o implementing them... if you do
implement them, every implementation is doing exactly the same
thing.
Gregg Kellogg: The risk is that we don't get good analysis from
people that don't implement it.
Niklas Lindström: I'm leaning towards gregg's notion - a bit
more lenience in how to implement an algorithm and ensure that
test cases cover all the corner cases that might crop up is the
best approach. We may want a comment in the spec about edge cases
- state the intent in the algorithm.
Gregg Kellogg: We could put more detail in an algorithm in the
appendix would be better. We don't want to subject readers to all
the corner cases that we're trying to document.
Dave Longley: i think that if you follow the algorithm in the
spec you should pass the test suite
Markus Lanthaler: I agree
Niklas Lindström: me too...
Niklas Lindström: I'd probably be a +0 on this, leaving too much
to interpretation is dangerous.
Dave Longley: one sec
Dave Longley: was talking ... not working.
Dave Longley: software issues over here.
Gregg Kellogg: I'd like to see some spec text, if it's simple
then fine... if it's complex, then not okay.
Dave Longley: i was going to say that other specifications , in
my experience, generally spell out how to write a fully
conformant processor
Manu Sporny: We'll ask Dave Longley to send some spec text to
RDF comments.
Dave Longley: and that, at least when i'm reading a spec to try
and implement it, i'd prefer it to be that way
Dave Longley: i think one should be able to just read the spec,
following the language --- and write code as you go, resulting in
something that passes the test suite.
Dave Longley: if you want to go off on your own and change the
algorithm or try and improve upon it, that's fine (and
encouraged, i'd think)
Dave Longley: but, at a minimum, i don't think implementors
should have to figure out their own algorithms if they don't want
to
ACTION: Dave Longley to send suggested spec text to modify the algorithm
to public-rdf-comments@w3.org
Dave Longley: i do think it's somewhat annoying to write the spec
language :), however, i don't think that that is a good reason to
not do it
Dave Longley: yes
Gregg Kellogg: To respond to Dave Longley, there has been some
evidence that spec algorithm complexity has prevented folks from
getting into the specs a bit further.
Gregg Kellogg: I'd like them to be able to participate w/o being
buried in details.
Gregg Kellogg: I have an action to annotate RDF algorithms to
make it more clear about what's going on.
Dave Longley: prevented implementors from getting into the specs
or users of the APIs?
Dave Longley: because i think that might be a presentation issue
if it's just the users of the APIs
Dave Longley: i can see it being frustrating, when writing an
implementation, that you don't pass the test suite ...
Dave Longley: and the spec document doesn't spell out why
Dave Longley: i don't think that's something that an implementor
wants to spend their time on
Dave Longley: i guess i'm ok with the spec spelling it out in
another section ... but i don't know what that really buys us
Dave Longley: and that it might just make it more complex to
implement (having to jump around the spec to find caveats, etc)
Manu Sporny: I think there are good arguments from both sides -
algorithms too high-level, interoperability problems. algorithms
too low-level, hard for people to contribute.
Gregg Kellogg: I do agree that test cases shouldn't come out of
nothing... there should be spec text backing them up. Having test
cases should protect against some of these corner cases.
Balancing act.
Niklas Lindström: I wonder if there is room for internal
re-factoring? For example, in RDFa algorithm there are references
from high-level text (in the algorithm) to low-level text in the
spec (elsewhere in the spec).
Dave Longley: if we simply spell out that prefix dependencies
have to be resolved and cycles must generate errors -- and then
we craft test cases that expose the corner cases, then i can
compromise and agree to that.
Manu Sporny: Dave, yeah, I think that's where we are right now.
Dave Longley: i worry that we don't currently have those corner
cases -- and that it's difficult to generate them, however.
(doesn't mean they won't show up in the real world)
Gregg Kellogg: I think the term selection algorithm is an
example of this right now, it's very complicated. We could
simplify it, but the result might not be that desirable when
faced with complicated input.
Niklas Lindström: I think the important part is that when the
data is very complex, you want to make each part distinct.
created/date and created/datetime are important to differentiate
in complex data.
Gregg Kellogg: I'm concerned about the geometric complexity that
is added when we support all of these corner cases, we may just
want to punt on some of this stuff.
Dave Longley: another thing to be concerned with is that if we
don't spec some of this stuff out, then the algorithms that are
in the spec might be fundamentally incompatible with a working
implementation
Dave Longley: as in, if we have a very detailed way of looping
over keys in a context during processing ... but in order to
properly resolve dependencies we must not loop (not saying this
is the case)
Dave Longley: then we've spec'd out something that doesn't
actually work when you take into consideration the other parts of
the spec that aren't spec'd in detail.
Manu Sporny: Okay, that's the call for today, we'll meet again
next week.
-- manu
--
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Which is better - RDFa Lite or Microdata?
http://manu.sporny.org/2012/mythical-differences/