- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 05 Mar 2013 12:26:29 -0500
- To: Linked JSON <public-linked-json@w3.org>
- CC: RDF WG <public-rdf-wg@w3.org>
Thanks to Gregg for scribing! The minutes from today's telecon are now
available.
http://json-ld.org/minutes/2013-03-05/
Full text of the discussion follows including a link to the audio
transcript:
--------------------
JSON-LD Community Group Telecon Minutes for 2013-03-05
Agenda:
http://lists.w3.org/Archives/Public/public-linked-json/2013Mar/0006.html
Topics:
1. ISSUE-218: Algorithm specification updates by editors
2. JSON-LD Property Generators
3. ISSUE-221: Inverse properties in JSON-LD
4. ISSUE-223: JsonLdOptions base vs. @base
5. JSON-LD latest API issues
Resolutions:
1. Remove Property Generators from JSON-LD before Last Call
due to no developers needing the feature, the feature having a
high potential of misuse, and because of the complexity it adds
to the specification.
2. Put JSON-LD Inverse Properties into the JSON-LD 1.0
specification as an at-risk feature.
3. 'base' (passed in via the API) sets the document base,
@base (in the document) overrides any value set by 'base' (passed
in via the API).
4. Allow @base to be set to the empty string. If @base is set
to the empty string, relative IRIs are processed according to RFC
3986 Section 5.2.2 (which is how they're always processed in
JSON-LD).
Action Items:
1. Gregg to look at adding support in ReSpec for auto-quoting
variable names in algorithms.
Chair:
Manu Sporny
Scribe:
Gregg Kellogg
Present:
Gregg Kellogg, Manu Sporny, Markus Lanthaler, Dave Longley,
Niklas Lindström, Paul Kuykendall, Lin Clark
Audio:
http://json-ld.org/minutes/2013-03-05/audio.ogg
Gregg Kellogg is scribing.
Topic: ISSUE-218: Algorithm specification updates by editors
Manu Sporny: https://github.com/json-ld/json-ld.org/issues/218
Manu Sporny: Let's pick up at 5.10 Compaction Algorithm
Markus Lanthaler: should we use call time for this?
Manu Sporny: history shows that if we don't, it doesn't happen
offline
Manu Sporny: most things are checked, we should be able to get
through it in 30 minutes
Markus Lanthaler: the comment was if we need to describe how a
shallow copy is made, as there is a lot of detail.
… Since properties can be added or deleteted, that shouldn't
happen.
… Do we need to explain in such detail? Or, just say "create a
shallow copy".
Dave Longley: people might implement it incorrectly. You can't
just copy the properties and reference the array; it's actually
two-level.
Manu Sporny: I think that's too vague. A "two-level shallow
copy" raises more questions.
Gregg Kellogg: Perhaps we can say do a "two-level shallow copy"?
[scribe assist by Manu Sporny]
Markus Lanthaler: I think most languages would also copy arrays
Dave Longley: I think just PHP does this, most other languages
don't. Just the keys would be copied, and the arrays referenced.
Manu Sporny: 5.12 Inverse Context Creation Subalgorithm
Markus Lanthaler: similar point; in some steps it is also overly
explicit in how to do things.
… As described, I wouldn't understand that it should be a
pointer; we should be a bit more explicit that we mean a pointer.
… In this case, it's not a shallow copy.
Dave Longley: this happens a couple of places in the spec where
we want to create a temporary variable. We also have the issue
where gkellogg would like the algorithms to be described more
"mathemetically".
… Not sure what language we should use. We might say "set to a
reference of a member".
Markus Lanthaler: it would be enough to say "set variable to a
reference of the value of key".
Dave Longley: we could say "reference the value of the key in
the map", or "let this variable identify the value of the key in
the map"
Manu Sporny: prefer the first form.
Dave Longley: "reference the value of the key in the map using
the variable foo"
Markus Lanthaler: makes sense.
Markus Lanthaler: +1
Manu Sporny: Next up is step 3.3.6
Markus Lanthaler: this is purely editorial. Checks are all
negative, it would be easier to be positive ("if there is a type
mapping, rather than if there is not a type mapping")
Now on 5.11 IRI Compaction Algorithm
Manu Sporny: suggest dropping the “parent” parameter...
Manu Sporny: about dropping the parent parameter here, and in
5.13
Dave Longley: this exists so that you don't remove things.
Markus Lanthaler: the question is if you remove the duplicates
in term selection or inside the compaction algorithm itself.
… Currently it's done in term selection, which also modifies
data. I think it's cleaner to make term selection and IRI
compaction to just return information, and leave modification to
the compaction algorithm.
… The first one where all duplicates are found is picked, and
duplicates are removed.
Dave Longley: my implementation doesn't remove data in term
selection.
... There is a flag for removing things, which is set to false
when called from term selection.
… The actual removal happens during compaction.
Markus Lanthaler: this means it loops over sub-trees twice.
… My selection is to not pass any data, but just return
candidates.
… The final selection is done in compaction.
… If there are property generators, you get back potential
property generators and a fallback term.
Dave Longley: this is less algorithmically correct, but seems
odd that term-selection doesn't actually select a term.
Manu Sporny: it seems to me that term selection should give a
single term.
Dave Longley: if you pass the parent, it can do the work for
you.
Manu Sporny: I'm wary of putting the feature at risk because
we've done the work.
Gregg Kellogg: JSON-LD is a better spec w/o property generators,
we should mark them as at-risk. [scribe assist by Manu Sporny]
Niklas Lindström: the amount of work put into it is an
indication of how complex it is.
Markus Lanthaler: implementing the algorithms doesn't mean that
someone knows what's actually going on.
Gregg Kellogg: I'm concerned about removing such a big
feature... we don't have a way of doing that if we remove the
feature. [scribe assist by Manu Sporny]
Manu Sporny: we need the correct text if we're going to take it
to LC. If it's going to be dropped, we can just stop discussion.
Manu Sporny: the timing is the thing.
… This would delay LC while we re-write the algorithms, after
asking lin and scor.
Markus Lanthaler: perhaps just talk about things other than
property generators?
Manu Sporny: 5.13 Term Selection Subalgorithm, second checkbox
Markus Lanthaler: dave used this to say if it is explicitly set
to null or something else. I think it would be easier to just use
@null.
Dave Longley: I think there was a test-case where the difference
in language mattered; perhaps default language.
Markus Lanthaler: my algorithm is almost exactly the same, and I
just use @null. I can't see where it would actually matter.
Dave Longley: if there were two terms, one used a null language,
and the other didn't, you'd need to be sure you didn't loose
that.
… It might be to simplify existence checks. We could change to
check for existence of entries instead.
… I'll take a look at it and try to clean it up.
Markus Lanthaler: next comment is if variables should be
different.
Manu Sporny: to address your concern about copy/paste into
comments, they should add quotes to make sure it's clear.
Dave Longley: this was brought up by prototypo, I just want to
be sure it's covered.
Manu Sporny: we could update ReSpec to add hidden back-ticks
around variables, so that they show up when copy/pasting.
Gregg Kellogg: I'll look into supporting something that makes
this simpler in ReSpec [scribe assist by Manu Sporny]
ACTION: Gregg to look at adding support in ReSpec for auto-quoting
variable names in algorithms.
Next up: 5.14 Value Compaction
Dave Longley: I think it was a difference of opinion on what the
style should be.
… One does a copy, the other doesn't and doesn't change things
until it needs to.
Markus Lanthaler: let's just not discuss value compaction now.
Topic: JSON-LD Property Generators
Manu Sporny: it sounded like there was concensus to remove
before LC.
… We should discuss with scor and lin, but the group would
like to remove it due to the great complexity added.
Paul Kuykendall: how would this affect the actual RDF being
created? Is it just a shortcut to not have to repeat yourself.
… I see that we have a use-case that could make use of this,
for example, when building out ontologies so that we can merge.
Markus Lanthaler: use case has to do with transforming to RDF?
Paul Kuykendall: we're using JSON-LD more like JSON/RDF
structure. We're generating some ontologies that define the
business domain and trying to tie them to other existing
ontologies (dc, schema, etc.).
… to allow customers better access into the data.
… For example, we have our own internal structure for
"address", which has a lot of cominality, using sameProperty
within the ontologies, that is expressed in the code.
… To say that these are the same thing.
… We to SPARQL inference in the client, and they then parse
out what they need.
Dave Longley: is it read-only?
Paul Kuykendall: they can write back. It may be SPARQL Update in
the future.
Gregg Kellogg: Well, the support you're showing for it might
mean we have to keep this feature... even if we don't like it
that much. [scribe assist by Manu Sporny]
Markus Lanthaler: you said you're defining ontologies, and
mapping them to DC, Schema and so forth?
Paul Kuykendall: yes; However, the clients don't necessarily
know about this mapping, as we can hide things behind the scene.
… If it turns out that they're really a bad idea, it's early
enough in our cycle that we could change.
Markus Lanthaler: the only change, if we drop property
generators, you would have to be explicit about having three
different properties.
Paul Kuykendall: the concern is that you have data-duplication
that it populates all of them and reduces the chanse of
programmer error.
… Making sure that all copies are updated, rather than just
one of three copies.
Markus Lanthaler: one of the problems with PG's is that if the
client expands and only changes one of the values, it wouldn't
compact back again.
Niklas Lindström: it is duplication, just hidden.
Paul Kuykendall: we use compacted form between client and
server.
… If I had the incorrect notion, maybe we should take this
out, so we don't have a mis-interpretation.
Dave Longley: there is nothing passed to tell how to re-compact,
just the values need to be the same.
Niklas Lindström: ..
http://www.w3.org/TR/rdfa-syntax/#vocabulary-expansion
Paul Kuykendall: that sounds like a great reason to get rid of
them, as it might be deceptively simple and create more problems
later on.
Niklas Lindström: describes RDFa mechanism for vocabulary
expansion.
Paul Kuykendall: My mis-understandings implies that other people
might also be confused about property generators.
Manu Sporny: there is no easy solution to your use-case. The
alternatives might actually be worse than property generators.
Markus Lanthaler: hi lin
Markus Lanthaler: we are currently discussing whether to drop
property generators for 1.0
Dave Longley: either way, your application is going to have to
keep track of what properties go together.
Manu Sporny: Wondering about possible future use of
property-generators in Drupal.
Lin Clark: at this point, I don't think they're a requirement
for us.
… We're focusing our use of JSON-LD to aligning ...
… We're not necessarily optimizing for smaller size, so it
should be okay from our stand-point.
Manu Sporny: seems like paul has a use case, but PGs don't fully
express it, and there is a fair chance of making things worse.
… Lin's use case has found a different solution.
… At this point, it doesn't seem we have anyone that really
needs them.
Markus Lanthaler: easier to remove now and re-introduce later
than the other way around.
Niklas Lindström: they border so much on semantics, that people
can use things like vocabulary expansion to do the same thing.
It's not syntactic, but semantically, it's already defined.
Dave Longley: I think the only way for them to work in the
future if we allow updates would be to include something in
expanded form, but for everyone converting to RDF, it wouldn't
work.
… People would have to program to understand the special
relationships between properties.
PROPOSAL: Remove Property Generators from JSON-LD before Last
Call due to no developers needing the feature, the feature having
a high potential of misuse, and because of the complexity it adds
to the specification.
Gregg Kellogg: +1
Manu Sporny: +1
Markus Lanthaler: +1
Dave Longley: +1
Niklas Lindström: +1
Paul Kuykendall: +1
RESOLUTION: Remove Property Generators from JSON-LD before Last
Call due to no developers needing the feature, the feature having
a high potential of misuse, and because of the complexity it adds
to the specification.
Topic: ISSUE-221: Inverse properties in JSON-LD
Manu Sporny: https://github.com/json-ld/json-ld.org/issues/221
Manu Sporny: a new feature requested, with a couple of
implementations.
... Of course, we're well past feature-freeze, even if they
seem simple to add.
Niklas Lindström: I've been using it since 2011, and at the
National Library I come across it all the time.
… Today, we abstracted people for which there exist not
descriptions, but we want to record the relationship anyway. For
example createorOr. There are no such properties, so using
^creator allows us to express this.
… Not all vocabularies define inverse properties, and certain
disciplines frown on explicitly defining inverses of properties.
… you naturally create things over time, you link a book to an
author, and don't always update the author to link back to the
book.
… I've felt needs for links to objects, such as RDF/SPARQL
Constructur results, or CBD's, where I want to root the
description in the primary object, and have things that link
to/from this.
… Filter authors/works, and works/authors. In many
expressions, it's useful to say the inversee.
Gregg Kellogg: Curious if you've implemented the round-tripping
bits of this? [scribe assist by Manu Sporny]
… I haven't implemented round-tripping in the code I have so
far. It's been a while, and I think I had something working in
the past.
… It seemed fairly simple to do, as long as you don't define
both to and from forms.
Markus Lanthaler: http://bit.ly/Xfy5vO
Markus Lanthaler: I implementier compaction, and it's quite
triveal.
… (example provided.)
… children expands to parent.
… It also takes into consideration if there is @reverse in the
data.
Niklas Lindström: this cleanly solves the two variants I had in
the past, but this is cleaner.
… I'd like to see it as you've implemented it.
Paul Kuykendall: we also have some use cases we're using on
where we need support for inverse relationships.
… We had to do a work around where we do inferencing on the
client side to look for inverse relationships, so it can
understand what properties to set.
… We do have a way around it, but this would be a nice to have
feature.
… We have a (barley adequate) workaround, but we need
something different.
Manu Sporny: would it be enough to create a description of how
it works, not include in JSON-LD 1.0, but all implementations
have the feature.
… Or, we have an implementation, and Markus could put his
algorithm in there, but we run a risk of standardizing something
that doesn't work for everyone.
Gregg Kellogg: I'm concerned that we might be putting this into
the spec before it's ready. I have some other feature additions
that might need further thought. Trying to solve everything at
this point is a recipe for disaster. I think we need to embrace
an "open specification" approach, and close the door on JSON-LD
1.0 Core in order to allow in order for people to start using it.
[scribe assist by Manu Sporny]
Gregg Kellogg: We can start adding features after that... easier
to put it in later than add it in now and possibly remove it
later. [scribe assist by Manu Sporny]
Niklas Lindström: it isn't new from my perspective, and is a
very natural feature when you express graphs as trees.
… We also have the BBC use, which is what brought this up.
Manu Sporny: would having it spec'd out elsewhere be enough?
… How many years before JSON-LD 1.1?
… If it's broadly implemented, it doesn't really matter if
it's in the core spec.
Markus Lanthaler: other specs would not be compliant, as they
must otherwise drop such properties or values.
… There are some special cases (no @id and @reverse), but it's
about an afternoon to make it solid.
PROPOSAL: Put JSON-LD Inverse Properties into the JSON-LD 1.0
specification as an at-risk feature.
Manu Sporny: -0.6
Niklas Lindström: +1
Markus Lanthaler: +1
Gregg Kellogg: +0.2
Dave Longley: +0.5
Paul Kuykendall: +.5
RESOLUTION: Put JSON-LD Inverse Properties into the JSON-LD 1.0
specification as an at-risk feature.
Topic: ISSUE-223: JsonLdOptions base vs. @base
Manu Sporny: https://github.com/json-ld/json-ld.org/issues/223
Manu Sporny: since we have @base keyword, should we have
something you can pass into the API?
… I think so, but @base always overrides this.
Markus Lanthaler: what is @base used for in JSON-LD? Is it also
used for compaction?
PROPOSAL: 'base' (passed in via the API) sets the document base,
@base (in the document) overrides any value set by 'base' (passed
in via the API).
Gregg Kellogg: +1
Manu Sporny: +1
Paul Kuykendall: +1
Dave Longley: +1
Niklas Lindström: +1
Markus Lanthaler: +1
RESOLUTION: 'base' (passed in via the API) sets the document
base, @base (in the document) overrides any value set by 'base'
(passed in via the API).
Dave Longley: I think we should allow the empty string ("") be
specified, so that you can say there is no base.
Gregg Kellogg: I use stuff like that to specify that things
should be able to be expressed via relative IRIs... it makes the
document work if it's served via any location. [scribe assist by
Manu Sporny]
… this would allow for the use of IRIs, so you'd keep relative
IRIs.
… (reverses scribe's understanding).
… If you use @base "" it means to not change them, relative
IRIs come in and go back out, for example in @id.
Markus Lanthaler: What happens if you do this?
'../test/.../hello' does it get compacted to this? '../hello' ?
[scribe assist by Manu Sporny]
Dave Longley: should be no changes. If you specify @base: "",
make no changes to IRIs on input.
… This does not rule out using terms and @id.
… My preference is to do no processing at all; a way of saying
"don't touch my IDs"
Manu Sporny: I don't know how standard this is, how many other
serializations say don't touch IRIs.
… Not doing path normalization might be a problem.
Markus Lanthaler: can we stay silent?
Manu Sporny: we need a test-case for it.
Niklas Lindström: .. "you can also pass an empty string and see
what happens" ;)
Dave Longley: if we do this sort of normalization, it will
impact normalization algorithms.
Markus Lanthaler:
http://tools.ietf.org/html/rfc3986#section-5.2.2
Markus Lanthaler: my read of the specs, is that paths would be
resolved.
Dave Longley: we link to the spec, and say that.
Markus Lanthaler: process them as they're always processed in
JSON-LD.
PROPOSAL: Allow @base to be set to the empty string. If @base is
set to the empty string, relative IRIs are processed according to
RFC 3986 Section 5.2.2 (which is how they're always processed in
JSON-LD).
Gregg Kellogg: +1
Dave Longley: +1
Niklas Lindström: +1
Manu Sporny: +1
Markus Lanthaler: +1
Paul Kuykendall: +1
RESOLUTION: Allow @base to be set to the empty string. If @base
is set to the empty string, relative IRIs are processed according
to RFC 3986 Section 5.2.2 (which is how they're always processed
in JSON-LD).
Topic: JSON-LD latest API issues
Paul Kuykendall: Is the diff-marked version broken here?
http://json-ld.org/spec/latest/json-ld-api/
Manu Sporny: The diff-marked version for the live spec is always
broken, you can try using the 'diffmark tool' in the live version
of the spec.
Markus Lanthaler: Try doing this: CTRL+SHIFT+ALT+S then click on
'diffmark'
Paul Kuykendall: we're fixing our APIs to be closer to the
latest spec, would be nice to know what changed.
Manu Sporny: You're probably going to have to save a local copy
and run the 'htmldiff.pl' script between the version you used to
implement and the current version (saved as a static file via
CTRL-SHIFT-ALT-S).
-- manu
--
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
President/CEO - Digital Bazaar, Inc.
blog: Aaron Swartz, PaySwarm, and Academic Journals
http://manu.sporny.org/2013/payswarm-journals/
Received on Tuesday, 5 March 2013 17:26:57 UTC