- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 10 Apr 2012 12:23:25 -0400
- To: Linked JSON <public-linked-json@w3.org>
The minutes from today's call are now available here:
http://json-ld.org/minutes/2012-04-10/
Full text of the discussion follows, the audio transcript will be
uploaded later today:
--------------------
JSON-LD Community Group Telecon Minutes for 2012-04-10
Agenda:
http://lists.w3.org/Archives/Public/public-linked-json/2012Apr/0031.html
Topics:
1. ISSUE-91: Re-definition of keywords
2. ISSUE-92: Limit JSON-LD properties to one @list per
property
3. ISSUE-93: Keyword aliasing operation
4. ISSUE-99: @graph treatment when expanding
5. ISSUE-58: Specifying the active context for compaction
6. ISSUE-57: Should @context be minimized when compacting?
7. ISSUE-53: Remove normalization completely from JSON-LD API
spec
Resolutions:
1. When performing expansion properties that are coerced to a
@container type of @list MUST be placed in an array in expanded
form. For example, "prop-iri": [{"@list": [1, 2]}] is correct,
"prop-iri": {"@list": [1, 2]} is not.
2. JSON-LD supports multiple aliases for a JSON-LD keyword.
3. Re-affirm that the aliasing of @context is disallowed due
to algorithmic complexity/ambiguity and lack of a compelling use
case.
4. A @context is processed without regard to keyword aliases.
Keyword aliases are taken into account when processing the body
of a JSON-LD document.
5. If @graph is the only property in the document's top level
object, it MUST be dropped in expansion and compaction. In all
other cases (which includes @graph at the document's top level
object when there are other properties other than @context at the
same level), @graph MUST NOT be dropped in expansion and
compaction.
6. The first input parameter for all JSON-LD API methods MAY
be an object, an array of objects, or an IRI (DOMString).
7. The second input parameter to the .compact() method is the
context that should be used for compaction. The value can be
either an object or an IRI.
8. The second input parameter to the .frame() method is the
frame that should be used for compaction. The value can be either
an object or an IRI.
9. If the optimize flag is not set, the context used for
compaction MUST be included without modifications in the
resulting document. This applies to both context objects as well
as contexts specified by passing an IRI. If the optimize flag is
set, a processor is free to modify the context in order to
optimize the resulting document body.
10. Remove the normalization algorithm and API from the
JSON-LD API specification. The normalization algorithm will be
placed into a separate RDF Graph Normalization specification
which contains an API for retrieving a set of normalized
statements.
Chair:
Manu Sporny
Scribe:
Manu Sporny
Present:
Manu Sporny, Gregg Kellogg, Markus Lanthaler, Niklas Lindström,
David I. Lehn
Manu Sporny is scribing.
Manu Sporny: any updates or changes to the agenda?
Gregg Kellogg: We need to go back over the resolved issues and
make sure that we can close remaining open issues. Can we close
them, or what further action should be taken to close them? Or
are they obsolete?
Markus Lanthaler: Regarding the test suite - should we do the
split of the test suite?
Manu Sporny: I'd rather keep that in the current website for now
- keep them all in the same place.
Gregg Kellogg: We could use git submodules, but that gets
annoying.
Markus Lanthaler: It takes a while to download the website.
Manu Sporny: We could update the php to package up the test
suite and download it.
Niklas Lindström: I agree with Gregg - working with it online or
working with it as a web app has been very beneficial. If I have
to run tests locally, I want to be able to check in copies of the
tests to the repo - so I agree with Gregg.
David I. Lehn: btw, if git is too slow, github has a zip you can
download. may be faster?
David I. Lehn: It's on the main page - you can download it.
Niklas Lindström: It would be beneficial if it was just the
manifest and the tests.
Topic: ISSUE-91: Re-definition of keywords
https://github.com/json-ld/json-ld.org/issues/91
Manu Sporny: This is about changing how JSON-LD keywords work -
redefining keywords.
Niklas Lindström: General problem I have is with rdf:type - as
it is a regular relation. Not being able to re-define @type is
fine with me, if you can create a regular keyword and map it
forrdf:type.
Niklas Lindström: I do it in the third example in the issue. I
don't really know if the algorithm supports this.
Niklas Lindström: If i need to control the way rdf:type is used
in compact form, can I?
Markus Lanthaler: Currently in compaction/expansion, nothing
would prevent you from doing the thing in your 3rd example.
Niklas Lindström: Would my definition of @type take precedence
over @type.
Markus Lanthaler: If you have @type in your document and you
expand it, it doesn't get expanded to rdf:type in your document -
they don't collide.
Gregg Kellogg: @type without a ??? is just another property -
there is no issue in JSON-LD, the issue comes in when you
round-trip.
Niklas Lindström: I can live with that from a matching point of
view - when I compact, what is going to happen? Can I always
force rdf:type to always be a set?
Gregg Kellogg: If you define something like 'a', then it will
work just like any other definition.
Niklas Lindström: In my first two examples - they emulate what
@type does, right?
Gregg Kellogg: No, @type doesn't expand... whereas 'a' would.
Niklas Lindström: In the 3rd example, I used 'rdf:type' without
using '@type'.
Discussion around 3rd example and round-tripping.
Manu Sporny: It seems like this usage patter is a little
strange.
Gregg Kellogg: You can support this with a frame.
Gregg Kellogg: The other question here is why we treat @type
differently from other properties?
Niklas Lindström: That's what I'm asking here.
Gregg Kellogg: It might be good to specify @type as another
property - this might create issues for framing, where framing
requires a particular pattern.
Niklas Lindström: Someone on-list asked for something to this
effect.
Niklas Lindström: We could solve this, but would have to be
careful about not complicating things.
Niklas Lindström: If someone defines another term for rdf:type,
then it should be treated like any other property.
Gregg Kellogg: That's too much special magic - we either demote
@type to be just like any property, or you use framing.
Niklas Lindström: We have special casing for @type already, it's
just where to put it.
Markus Lanthaler: If you look at this from a JSON perspective,
it's the other way around.
Niklas Lindström: If you look at it from a Linked Data
perspective, @type represents a link - and you can have that as a
subject, you can have multiple types, etc.
Niklas Lindström: Unlike other relations, you can't say that
you'd always want it as a set container. If we want to change
@type back to a property, we may want to move things back from
@type to @datatype
Gregg Kellogg: @type means two things, based on where it is used
- if it's @type it might be in a value, it might be in array
form, in other cases, it might not be in array form. If we went
back to @datatype, we wouldn't have to complicate the code.
Gregg Kellogg: If we make @type in objects be like other
properties, it would reduce complexity.
Manu Sporny: So the pseudo-proposal is re-introduce @datatype.
Gregg Kellogg: yes, that would reduce code complexity - but we
should ask Dave Longley about this first.
Markus Lanthaler: Why do we have @type at all then?
Manu Sporny: Syntactic sugar that folks have come to expect...
easier to write code based off of it.
Markus Lanthaler: How is re-introducing @datatype different from
what we have now?
Gregg Kellogg: You can't override @datatype like you can
override @type.
Niklas Lindström: Even in JSON Schema, there is a different
between datatype given and relation to an object type.
Niklas Lindström: Even with JSON schema, which has nothing to do
with RDF, there is a distinction.
Niklas Lindström: .. re. json schema; they have "format":
http://tools.ietf.org/html/draft-zyp-json-schema-03#section-5.23
Niklas Lindström: .. in json-schema: format is defined as "This
property defines the type of data, content type, or microformat
to be expected in the instance property values"
Postponing decision on ISSUE-91 - topics that we need to address:
1) if we want to reintroduce @datatype, 2) if keywords can be
redefined, 3) if there is an initial context that specifies
'@type' as syntactic sugar (@type is just like any other
property)
Topic: ISSUE-92: Limit JSON-LD properties to one @list per property
https://github.com/json-ld/json-ld.org/issues/92
Manu Sporny: A property can have at most one @list associated
with it, that's what we're discussing here - due to complexity
for supporting more - throw an exception if more than one @list
is used.
Gregg Kellogg: I agree with that, there is another issue.
Gregg Kellogg: If there is a property that has @list coercion in
it, then something in array form may need to be put into a list -
we need to be consistent.
Gregg Kellogg: The main thing is what is the representation of
@list in expanded form?
Gregg Kellogg: Can a property have more than one @list in it.
Gregg Kellogg: What is the expression in expanded form?
Gregg Kellogg: We have a pattern that is different from
everything else we expand - if we show it in array form, it
implies that we can have more than one element - clear that there
can only be one list. It's an exception for the way values are
treated in expanded form - additional complexity in processing
algorithms.
Gregg Kellogg: You might have multiple properties that might
expand to the same IRI, when you go to merge the arrays, it
creates confusion on list order - two different lists or multiple
values in the same list?
Gregg Kellogg: This is an issue in expansion.
Markus Lanthaler: In expansion, it is just 3 separate lists,
right?
Gregg Kellogg: There are cases where you may have conflation -
it may be 3 separate lists, or it may be one list.
Gregg Kellogg: I don't see a use case that requires more than
one list in most cases - if you take that as a concern, then the
representation is a single object - I'd rather see it as an array
that holds a single object, not just a single object.
Gregg Kellogg: I don't think we want to go into the discussion
on supporting multiple lists of lists unless there is a
compelling use case.
Gregg Kellogg: Lists containing lists is extremely complicated.
Niklas Lindström: .. http://spinrdf.org/sp.html#sp-Union
Niklas Lindström: I think I agree from a practical point of view
- one very strange real-world use case ^^^
Niklas Lindström: Really don't expect that to be used in
JSON-LD. We should know that there is at least one case, and we
should throw an exception in that case.
Markus Lanthaler: Could we split this into sub-issues - one for
compaction, one for expansion.
Niklas Lindström: .. {"prop-iri": [{"@list": [1, 2]}]}
Manu Sporny: I wonder if we should push this decision off.
Gregg Kellogg: We should be able to discuss how expanded form
should look.
PROPOSAL: When performing expansion properties that are coerced
to a @container type of @list MUST be placed in an array in
expanded form. For example, "prop-iri"
Gregg Kellogg: +1
Manu Sporny: +1
Markus Lanthaler: +1
Niklas Lindström: +1
RESOLUTION: When performing expansion properties that are coerced
to a @container type of @list MUST be placed in an array in
expanded form. For example, "prop-iri": [{"@list": [1, 2]}] is
correct, "prop-iri": {"@list": [1, 2]} is not.
Gregg Kellogg: This was creating more corner-cases for us.
Gregg Kellogg: This will simplify the algorithm.
Markus Lanthaler: Maybe dlongley could add explicit examples.
Topic: ISSUE-93: Keyword aliasing operation
https://github.com/json-ld/json-ld.org/issues/93
Manu Sporny: Markus raises four questions - 1) Can multiple
aliases exist for a keyword? 2) Why is aliasing of @context
disallowed? 3) Are aliased keywords supported within a context?
4) How is this processed during contextprocessing/expansion/
compaction
Manu Sporny: I think we should allow multiple aliases for a
keyword, don't know for #2, I think we only support aliases being
used outside the context, defer to Gregg and Longley on #4
Markus Lanthaler: I agree with Dave and Gregg after discussion
with them.
PROPOSAL: JSON-LD supports multiple aliases for a JSON-LD
keyword.
Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
Markus Lanthaler: +1
RESOLUTION: JSON-LD supports multiple aliases for a JSON-LD
keyword.
PROPOSAL: Re-affirm that the aliasing of @context is disallowed
due to algorithmic complexity/ambiguity and lack of a compelling
use case.
Manu Sporny: +1
Markus Lanthaler: +1
Niklas Lindström: +1
Gregg Kellogg: +1
RESOLUTION: Re-affirm that the aliasing of @context is disallowed
due to algorithmic complexity/ambiguity and lack of a compelling
use case.
PROPOSAL: A @context is processed without regard to keyword
aliases. Keyword aliases are taken into account when processing
the body of a JSON-LD document.
Markus Lanthaler: +1
Gregg Kellogg: +1
Niklas Lindström: +1
Manu Sporny: +1
RESOLUTION: A @context is processed without regard to keyword
aliases. Keyword aliases are taken into account when processing
the body of a JSON-LD document.
The group notes that the processing rules for compaction,
expansion and framing are not affected by the previous 3
decisions.
Topic: ISSUE-99: @graph treatment when expanding
https://github.com/json-ld/json-ld.org/issues/99
Gregg Kellogg: I think that everyone agrees that the only time
that @graph is dropped is when it is the only property expressed
in a top-level object other than @context.
The current proposal is: If @graph is the only property in the
document's top level object, it MUST be dropped in expansion and
compaction. In all other cases (which includes @graph at the
document's top level object when there are other properties at
the same level), @graph MUST NOT be dropped in expansion and
compaction.
Manu Sporny: I'm concerned about how the RDF WG will react to
this - may be controversial.
Manu Sporny: This will affect normalization.
Gregg Kellogg: We need to be able to express graphs - Wikidata
folks need this - we don't want to not solve that application
because we haven't yet solved the graph issue.
Gregg Kellogg: this isn't a big complication to any of our
algorithms
Gregg Kellogg: The interpretation when it comes to RDF is the
tricky part - but I don't see it as that tricky
PROPOSAL: If @graph is the only property in the document's top
level object, it MUST be dropped in expansion and compaction. In
all other cases (which includes @graph at the document's top
level object when there are other properties other than @context
at the same level), @graph MUST NOT be dropped in expansion and
compaction.
Gregg Kellogg: +1
Markus Lanthaler: +1
Manu Sporny: +1
Niklas Lindström: +1 with a bit of faith
RESOLUTION: If @graph is the only property in the document's top
level object, it MUST be dropped in expansion and compaction. In
all other cases (which includes @graph at the document's top
level object when there are other properties other than @context
at the same level), @graph MUST NOT be dropped in expansion and
compaction.
Manu Sporny: Those were all the discussions related to syntax,
now on to API issues.
Topic: ISSUE-58: Specifying the active context for compaction
https://github.com/json-ld/json-ld.org/issues/58
Manu Sporny: We are starting to have a great number of options
for these API methods
Gregg Kellogg: We should probably put these in options.
Markus Lanthaler: What about mandatory arguments, like the
context for compaction, or the base IRI?
Gregg Kellogg: We should discuss allowing passing IRIs or file
objects to the compaction, expansion, etc. algorithms.
Manu Sporny: That's new, we'll have to discuss the signatures
for these methods.
Manu Sporny: Should we focus the API on higher-level languages
only?
Gregg Kellogg: I think so.
Discussion around arguments to API methods - whether there should
be an 'option' object, or if mandatory options should be separate
from 'options', such as the compacting context in the call to
.compact().
Discussion concerning what the arguments can be for the input
parameters.
Markus Lanthaler: http://dev.w3.org/2006/webapi/WebIDL/#idl-union
Markus Lanthaler: (float or float[])
PROPOSAL: The first input parameter for all JSON-LD API methods
MAY be an object, an array of objects, or an IRI (DOMString).
Markus Lanthaler: +1
Manu Sporny: +1
Gregg Kellogg: +1
RESOLUTION: The first input parameter for all JSON-LD API methods
MAY be an object, an array of objects, or an IRI (DOMString).
PROPOSAL: The second input parameter to the .compact() method is
the context that should be used for compaction. The value can be
either an object or an IRI.
Manu Sporny: +1
Gregg Kellogg: +1
Markus Lanthaler: +1
Gregg Kellogg: +1
RESOLUTION: The second input parameter to the .compact() method
is the context that should be used for compaction. The value can
be either an object or an IRI.
PROPOSAL: The second input parameter to the .frame() method is
the frame that should be used for compaction. The value can be
either an object or an IRI.
Gregg Kellogg: +1
Markus Lanthaler: +1
Manu Sporny: +1
RESOLUTION: The second input parameter to the .frame() method is
the frame that should be used for compaction. The value can be
either an object or an IRI.
Topic: ISSUE-57: Should @context be minimized when compacting?
https://github.com/json-ld/json-ld.org/issues/57
PROPOSAL: If the optimize flag is not set, the context used for
compaction MUST be included without modifications in the
resulting document. This applies to both context objects as well
as contexts specified by passing an IRI. If the optimize flag is
set, a processor is free to modify the context in order to
optimize the resulting document body.
Markus Lanthaler: I think we all agree on this...
Gregg Kellogg: +1
Markus Lanthaler: +1
Manu Sporny: +1
RESOLUTION: If the optimize flag is not set, the context used for
compaction MUST be included without modifications in the
resulting document. This applies to both context objects as well
as contexts specified by passing an IRI. If the optimize flag is
set, a processor is free to modify the context in order to
optimize the resulting document body.
Topic: ISSUE-53: Remove normalization completely from JSON-LD API spec
https://github.com/json-ld/json-ld.org/issues/53
Discussion about how this would be implemented across
specification documents.
Gregg Kellogg: We don't need normalization in the JSON-LD API,
it belongs in a normalization API.
Manu Sporny: So the 'normalization spec' should describe how to
normalize RDF graphs and it should outline an API call to get
back a list of quads that is normalized and sorted.
Manu Sporny: other issue is which bits to pull from the RDF API
spec.
PROPOSAL: Remove the normalization algorithm and API from the
JSON-LD API specification. The normalization algorithm will be
placed into a separate RDF Graph Normalization specification
which contains an API for retrieving a set of normalized
statements.
Manu Sporny: +1
Markus Lanthaler: +1
Gregg Kellogg: +1
RESOLUTION: Remove the normalization algorithm and API from the
JSON-LD API specification. The normalization algorithm will be
placed into a separate RDF Graph Normalization specification
which contains an API for retrieving a set of normalized
statements.
--
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Website for Developers Launched
http://digitalbazaar.com/2012/02/22/new-payswarm-alpha/
Received on Tuesday, 10 April 2012 16:24:10 UTC