- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 11 Jun 2013 12:43:49 -0400
- To: Linked JSON <public-linked-json@w3.org>
- CC: RDF WG <public-rdf-wg@w3.org>
Thanks to Niklas for scribing! The minutes from this week's telecon are
now available.
http://json-ld.org/minutes/2013-06-11/
Full text of the discussion follows including a link to the audio
transcript:
-------------------------------------------------------------------
JSON-LD Community Group Telecon Minutes for 2013-06-11
Agenda:
http://lists.w3.org/Archives/Public/public-linked-json/2013Jun/0026.html
Topics:
1. json-ld.org updates
2. RDF-ISSUE-135: Government Linked Data (GLD) Working Group
Feedback
3. ISSUE-253: Reverse term definition modifications
4. RDF and JSON-LD Alignment issue.
5. Relationship to RDF model in syntax spec should be
normative
6. Editorial changes to JSON-LD Syntax
7. Conversion of blank nodes to Skolemization IDs when going
to RDF
Resolutions:
1. Allow "@container": "@set" for reverse properties.
2. Remove the @type restriction for reverse properties. This
also means that a reverse property won't be implicitly
type-coerced to @id anymore.
3. Add the following normative text to the JSON-LD Syntax
specification: The normative algorithm for interpreting JSON-LD
as RDF is specified in the JSON-LD Processing Algorithms and API
specification [JSON-LD-API].
4. Make David Booth's bullet-point addition to the JSON-LD
Syntax spec: " * Software developers who want to generate or
consume Linked Data, an RDF graph or an RDF Dataset in a JSON
syntax."
5. Add spec text to the following effect into the JSON-LD
Syntax specification: JSON-LD was designed to be usable directly
as JSON, with no knowledge of RDF, but was designed also to be
usable as RDF (if desired), for use with other Semantic Web
technologies like SPARQL. People intending to use JSON-LD with
RDF tools will find it can be used as another RDF syntax, like
Turtle. Complete details of how JSON-LD relates to RDF are in
Appendix C.
6. Make other editorial changes as needed to avoid implying
that JSON-LD is not necessarily RDF.
7. Add spec text to JSON-LD Syntax. Appendix C: JSON-LD is a
_concrete RDF syntax_ as described in [RDF11_CONCEPTS]. Hence, a
JSON-LD document is both an RDF document and a JSON document and
correspondingly represents both an instance of the RDF data model
and an instance of the JSON-LD data model.
Chair:
Manu Sporny
Scribe:
Niklas Lindström
Present:
Manu Sporny, Niklas Lindström, Vikash Agrawal, Markus Lanthaler,
David Booth, Dave Longley, Gregg Kellogg, Paul Kuykendall, Sandro
Hawke
Audio:
http://json-ld.org/minutes/2013-06-11/audio.ogg
Manu Sporny: Any updates to the Agenda?
Manu Sporny: We need to discuss RDF/JSON-LD alignment
Vikash Agrawal: Need to do a GSoC update :-)
Markus Lanthaler: We have a datatype bug -
https://github.com/json-ld/json-ld.org/issues/257
Niklas Lindström is scribing.
Topic: json-ld.org updates
Vikash Agrawal: thanks to markus for help with github etc.
... good web page progress, moving on to the playground. I
should be able to integrate my github pull requests soon.
Topic: RDF-ISSUE-135: Government Linked Data (GLD) Working Group Feedback
Manu Sporny: http://www.w3.org/2011/rdf-wg/track/issues/135
Markus Lanthaler:
https://github.com/json-ld/json-ld.org/issues/254
Manu Sporny: markus has reviewed, fixed and given feedback to
GLD on most issues
Markus Lanthaler: some issues left in the tracker which we need
to go through
Manu Sporny: ... first point will fold into our next topic
(json-ld in relation to rdf)
Manu Sporny:
https://github.com/json-ld/json-ld.org/issues/254#issuecomment-19156384
Markus Lanthaler: 1.S3 IRI vs. URI/URL
Manu Sporny: we've decided upon IRI, since its technically
correct
Markus Lanthaler: changing toRDF algorithm to drop BNodes where
not allowed (instead of skolemizing)
David Booth: -1 to dropping the data
Manu Sporny: anyone else for dropping?
No responses in favor of dropping.
Markus Lanthaler: all the remaining issues are mainly editorial
Manu Sporny: we can discuss the rest on the mailing list or
issue tracker, then
Topic: ISSUE-253: Reverse term definition modifications
Manu Sporny: https://github.com/json-ld/json-ld.org/issues/253
Markus Lanthaler: when reverse properties were introduced, we
did that in a minimal way, restricting e.g. @container to @index
... this is problematic for deterministic compaction, by e.g.
ensuring @set
... also, @type: @id makes sense since only IRIs/bnodes are
valid subjects – but the form would not be deterministic if mixed
references and objects with other values are used
Markus Lanthaler:
https://github.com/json-ld/json-ld.org/issues/253#issuecomment-19168635
... I've checked the spec and there are only four minor points
which need to be altered, to be considered a bug fix in order to
support deterministic shapes
... these to proposals will make this consistent with how
other properties work
Manu Sporny: are there downsides other than no automatic type
coercion?
Markus Lanthaler: only that the context becomes a bit larger if
you only use references, since with this change you have to
specify @type: @id explicitly
PROPOSAL: Allow "@container": "@set" for reverse properties.
Niklas Lindström: +1
Dave Longley: +1
Markus Lanthaler: +1
Manu Sporny: +1
Gregg Kellogg: +1
Paul Kuykendall: +1
Vikash Agrawal: +1
RESOLUTION: Allow "@container": "@set" for reverse properties.
PROPOSAL: Remove the @type restriction for reverse properties.
This also means that a reverse property won't be implicitly
type-coerced to @id anymore.
Markus Lanthaler: +1
Dave Longley: +1
Manu Sporny: +1
Paul Kuykendall: +1
Gregg Kellogg: +1
Niklas Lindström: +1
Manu Sporny: was this marked as at risk?
Markus Lanthaler: the entire feature was it, yes
Gregg Kellogg: this fix is in response to LC feedback
Manu Sporny: and this is considered a bug fix for an
inconsistency
RESOLUTION: Remove the @type restriction for reverse properties.
This also means that a reverse property won't be implicitly
type-coerced to @id anymore.
Topic: RDF and JSON-LD Alignment issue.
Manu Sporny: we've had a number of RDF/JSON-LD alignment
discussions throughout this work
David Booth: Can we separate the issues of the re-definition of
"Linked Data" from other alignment issues, to eat the elephant
one piece at a time?
... we've tried to find an acceptable balance, but the last
days” discussion show this is not the case
... let's focus on specific proposals to +1/-1 on
... there are some editorial and some normative suggestions.
Maybe we can start with background on your major concerns, David
(Booth)?
Sandro Hawke: yes
David Booth: let's focus on the (re)definition of Linked Data
separately
Sandro Hawke: (leaving IRC)
... that term is very important in the semweb community, and
it's important to not redefine it
... With respect to the normative stuff; based on discussions
with gregg, the WG intended the RDF alignment to be normative
originally..
... i.e. the mapping to the RDF model
... this is not apparent by reading the syntax spec
... it explicitly says that it is not normative. This sounds
like an editorial issue.
... Separately, I also suggest that the skolemization of
graph/predicate bnodes is made normative
Dave Longley: three issues: 1. linked data redefinition, 2.
relationship to RDF model in syntax spec should be normative
(editorial), 3. skolemization should be normative
Manu Sporny: so three issues in total: 1) Linked Data
definition, 2) normative relation to the RDF model 3) normative
skolemization [correct?]
Topic: Relationship to RDF model in syntax spec should be normative
Manu Sporny: I think the CG agrees in principle
Gregg Kellogg: as I recall, we tried to avoid circular
dependencies
Manu Sporny: we did it since the API spec might not progress at
the same rate
Sandro Hawke: I think david's wording from yesterday is that the
mapping is provided normatively in the other spec; but the syntax
spec doesn't reference it normatively
David Booth: making this reference normative would address my
issue
David Booth: a question regarding the conformance statement, is
that complete? let's leave that for now, to avoid confusiin
Gregg Kellogg: since we are on separate timelines, the RDF 1.1
is behind us, possibly slowing JSON-LD down [correct?]
Manu Sporny: so if we make the statement normative, that this is
now to map to RDF, that is enough?
David Booth: yes
David Booth:
http://lists.w3.org/Archives/Public/public-rdf-comments/2013Jun/0074.html
Markus Lanthaler:
http://json-ld.org/spec/latest/json-ld/#relationship-to-rdf
Manu Sporny: do we also need to reference to the RDF 1.1
concepts in this statement, in the syntax spec?
David Booth: I'm proposing we make this change: The normative
algorithm for interpreting JSON-LD as RDF is specified in the
JSON-LD Processing Algorithms and API specification
[JSON-LD-API].
Markus Lanthaler: I would be fine with that change
David Booth: interpreting as RDF, and serializing as JSON-LD
Gregg Kellogg: think of how this would read if it were turtle:
we don't want to paint a difference that's not there
David Booth: agreed
Sandro Hawke: in turtle and rdf/xml, we can just say parsing as
RDF, but jn JSON-LD, it's more about converting to..
PROPOSAL: Add the following normative text to the JSON-LD Syntax
specification: The normative algorithm for interpreting JSON-LD
as RDF is specified in the JSON-LD Processing Algorithms and API
specification [JSON-LD-API].
David Booth: +1
Manu Sporny: +1
Niklas Lindström: +1
Gregg Kellogg: +1
Markus Lanthaler: could you add "in section C. Relationship to
RDF"?
Paul Kuykendall: +1
Dave Longley: +1 (but should align the language with the changes
requested in the JSON-LD API spec)
Markus Lanthaler: +1, if this goes into section C. Relationship
to RDF
Manu Sporny: we divided this up like this because we wanted to
explain the tech clearly, and the best place for conversion is in
the algorithms spec, because it is very detailed
David Booth: put pat hayes' point in an appendix?
RESOLUTION: Add the following normative text to the JSON-LD
Syntax specification: The normative algorithm for interpreting
JSON-LD as RDF is specified in the JSON-LD Processing Algorithms
and API specification [JSON-LD-API].
Manu Sporny: though those details are not for the intended
audience
David Booth: I'm fine with this change
Topic: Editorial changes to JSON-LD Syntax
David Booth: What about this change, in section 1
David Booth:
https://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld/index.html#introduction
David Booth: Make the following editorial change to clarify and
move the mention of RDF slightly later in the document. Delete
the sentence: "Developers that require any of the facilities
listed above or need to serialize anRDF graph or dataset
[RDF11-CONCEPTS] in a JSON-based syntax will find JSON-LD of
interest.". Instead, add the following bullet item to the
existing bullet list in section 1.1:
David Booth: - "Software developers who want to generate or
consume Linked Data, an RDF graph or an RDF Dataset in a JSON
syntax."
Manu Sporny: a parallell proposal is sandro's proposal
Manu Sporny: Sandro proposed: JSON-LD was designed to be
compatible with Semantic Web technologies like RDF and SPARQL.
People intending to use JSON-LD with RDF tools will find it can
be used as another RDF syntax, like Turtle. Complete details of
how JSON-LD relates to RDF are in Appendix C.
Sandro Hawke: I think I prefer david's proposal
David Booth: I would be fine with either one. I like Sandro's
mention of Appendix C though.
Gregg Kellogg: I like both, sando's could go elsewhere
David Booth: +1 to using both, with sandro's later
Dave Longley: though "compatible with" might send the wrong
signal about a difference that's not there
Gregg Kellogg: good to note that also JSON usage is taken into
account
David Booth: yes, tweak sandro's to change "compatible with"
Manu Sporny: the note should be crystal clear that these are not
considered as alternative technologies
Gregg Kellogg: JSON-LD allows you to write idiomatic JSON, but
have it interpreted as RDF [scribe assist by Manu Sporny]
Gregg Kellogg: spell out that JSON-LD allows you to write
idiomatic JSON, *and* to interpret it as RDF (c.f. RDFa allowing
you to write HTML..)
Markus Lanthaler: david wood asked us to add that sentence at
the end of the introduction (suggested to be deleted)
... we should not do that without consulting David Wood.
PROPOSAL: Make David Booth's bullet-point addition to the JSON-LD
Syntax spec: " * Software developers who want to generate or
consume Linked Data, an RDF graph or an RDF Dataset in a JSON
syntax."
Manu Sporny: +1
Dave Longley: +1
Niklas Lindström: +1
Markus Lanthaler: +1
Gregg Kellogg: +1
Paul Kuykendall: +1
David Booth: +1
RESOLUTION: Make David Booth's bullet-point addition to the
JSON-LD Syntax spec: " * Software developers who want to generate
or consume Linked Data, an RDF graph or an RDF Dataset in a JSON
syntax."
David Booth: Proposed revision of Sandro's text: JSON-LD was
designed to be usable directly as JSON, but also as RDF (if
desired), for use with other Semantic Web technologies like
SPARQL. People intending to use JSON-LD with RDF tools will find
it can be used as another RDF syntax, like Turtle. Complete
details of how JSON-LD relates to RDF are in Appendix C.
Manu Sporny: making it clear that neither RDF nor SPARQL is
needed to use JSON-LD, but also that it is designed to work as
RDF
David Booth: JSON-LD was designed to be usable directly as JSON,
with no knowledge of RDF, but was designed also to be usable as
RDF (if desired), for use with other Semantic Web technologies
like SPARQL. People intending to use JSON-LD with RDF tools will
find it can be used as another RDF syntax, like Turtle. Complete
details of how JSON-LD relates to RDF are in Appendix C.
PROPOSAL: Add spec text to the following effect into the JSON-LD
Syntax specification: JSON-LD was designed to be usable directly
as JSON, with no knowledge of RDF, but was designed also to be
usable as RDF (if desired), for use with other Semantic Web
technologies like SPARQL. People intending to use JSON-LD with
RDF tools will find it can be used as another RDF syntax, like
Turtle. Complete details of how JSON-LD relates to RDF are in
Appendix C.
Niklas Lindström: +1 to that
Gregg Kellogg: +1
Dave Longley: +1
David Booth: +1
Manu Sporny: +1
Markus Lanthaler: +1... could probably go into design goals
Paul Kuykendall: +1
RESOLUTION: Add spec text to the following effect into the
JSON-LD Syntax specification: JSON-LD was designed to be usable
directly as JSON, with no knowledge of RDF, but was designed also
to be usable as RDF (if desired), for use with other Semantic Web
technologies like SPARQL. People intending to use JSON-LD with
RDF tools will find it can be used as another RDF syntax, like
Turtle. Complete details of how JSON-LD relates to RDF are in
Appendix C.
David Booth: What about this change? 4. Without adding any
earlier mention of RDF than the JSON-LD spec already contains,
make other editorial changes as needed to avoid implying that
JSON-LD is not necessarily RDF. (However it is fine to say that
JSON-LD does not need to be *processed* as RDF.)
David Booth: Example: Change "Converting JSON-LD to RDF" to
either "Interpreting JSON-LD as RDF" or "Converting a JSON-LD
model to an RDF model".
David Booth: not say "converted to", but rather "interpreted as"
Markus Lanthaler: fine with "interpreting"
Dave Longley: yeah, that's fine
Gregg Kellogg: +1 to interpreting ...
Markus Lanthaler: algorithm names would sound a bit weird though
Dave Longley: For algorithms, maybe "produce RDF abstract syntax
from JSON-LD"?
David Booth: What about making other editorial changes as needed
to avoid implying that JSON-LD is not necessarily RDF. (However
it is fine to say that JSON-LD does not need to be *processed* as
RDF.)
Markus Lanthaler: dlongley, who understands what an abstract
syntax is?
Markus Lanthaler: :-)
PROPOSAL: Make other editorial changes as needed to avoid
implying that JSON-LD is not necessarily RDF.
Gregg Kellogg: +1
Niklas Lindström: +1
Dave Longley: +1
Manu Sporny: +1
David Booth: +1
Paul Kuykendall: +1
Markus Lanthaler: +1
RESOLUTION: Make other editorial changes as needed to avoid
implying that JSON-LD is not necessarily RDF.
Markus Lanthaler: dbooth, pull requests are welcome :-P
David Booth: And this change? 5. At the beginning of appendix C
insert: "JSON-LD is a _concrete RDF syntax_ as described in
[RDF11_CONCEPTS]. Hence, a JSON-LD document is both an RDF
document and a JSON document and correspondingly represents both
an instance of the RDF data model and an instance of the JSON-LD
data model."
Manu Sporny: though that hinges on the difference on bnode usage
and native datatypes basically you can do those 4 bullet points
in appendix c in JSON-LD, but not according RDF 1.1 concepts.
David Booth: so this is tied to the other topic
Gregg Kellogg: there are other differences, like the @ındex
feature which are purely syntactical stuff
David Booth: but that's ok
Gregg Kellogg: though those could be considered part of the
json-ld data model
Manu Sporny: like the native list and native numbers
Gregg Kellogg: but turtle has syntactically "native" lists
Dave Longley: can we just say: "JSON-LD can be interpreted as a
concrete RDF syntax" ?
Dave Longley: since there's a mapping?
David Booth: but that's an effect of the syntactic form, which
isn't a problem in relation to the abstract syntax
Manu Sporny: I don't see a problem either, but others in the RDF
WG had...
Gregg Kellogg: the option to transform numbers to native json
numbers could change this (to enable this interpretation of the
model relationship)
Sandro Hawke: I think they complained because it wasn't true at
the time. But I think we've just about fixed this, except maybe
for skolemization.
David Booth: My understanding is that this wording does reflect
the intent of the working group, and just makes it clearer.
Markus Lanthaler:
http://lists.w3.org/Archives/Public/public-rdf-comments/2013Jun/0086.html
Markus Lanthaler: So we got already a first response
PROPOSAL: Add spec text to JSON-LD Syntax. Appendix C: JSON-LD is
a _concrete RDF syntax_ as described in [RDF11_CONCEPTS]. Hence,
a JSON-LD document is both an RDF document and a JSON document
and correspondingly represents both an instance of the RDF data
model and an instance of the JSON-LD data model.
Manu Sporny: +0.5
Gregg Kellogg: +1
David Booth: +1
Niklas Lindström: +1
Dave Longley: +1
Markus Lanthaler: +0
Manu Sporny: sandro: +1
RESOLUTION: Add spec text to JSON-LD Syntax. Appendix C: JSON-LD
is a _concrete RDF syntax_ as described in [RDF11_CONCEPTS].
Hence, a JSON-LD document is both an RDF document and a JSON
document and correspondingly represents both an instance of the
RDF data model and an instance of the JSON-LD data model.
Topic: Conversion of blank nodes to Skolemization IDs when going to RDF
David Booth: This proposal? 1. In RDF conversion algorithms in
JSON-LD 1.0 Processing Algorithms and API,
http://json-ld.org/spec/latest/json-ld-api/#rdf-conversion-algorithms
David Booth: specify that **when JSON-LD is interpreted as RDF,**
(i.e., when the JSON-LD model is converted to the RDF model)
skolem IRIs MUST be generated using the well-known URI suffix
"json-ld-genid" for any JSON-LD blank node that would otherwise
be mapped to an RDF blank node in a position where an RDF blank
node is not permitted. Conversely, when RDF is serialized as
JSON-LD (or when an RDF model is converted to a JSON-LD model),
skolem IRIs having the well-known URI suffix "json-ld-genid"
SHOULD be serialized as JSON-LD blank nodes. Finally, register
the well-known URI suffix "json-ld-genid", in accordance with
RFC5785: http://tools.ietf.org/html/rfc5785
David Booth: BACKGROUND NOTE: The existing well-known URI suffix
"genid" is for converting to/from RDF blank nodes (in positions
where blank nodes are *permitted* in RDF), whereas
"json-ld-genid" will be used for *avoiding* blank nodes (in
positions where they are not allowed in RDF).
David Booth: some discussion about the well-known suffix name
(sandro suggested another one I'm fine with), or use the existing
name gen-id, created by the RDF WG. Though those would make it
harder for streaming processors to directly convert to bnodes
without looking at the context.
Sandro Hawke: I think it is always legal, specifically to
convert skolemized IRIs
Sandro Hawke: I think it's better to use normal gen-id:s
Markus Lanthaler: you end up with heaps of clashing bnode id:s
Manu Sporny: this is the decentralized identification problem
David Booth: The whole point of well-known suffixes is to prevent
clashes while allowing distributed minting of IRIs.
Manu Sporny: every time we discuss this, we go through the same
line of argumentation. First we propose skolem IDs, then we note
that skolem IDs can't be rooted in the same namespace, then we
decide that skolem IDs need to be generated in a very specific
way, then we back up to RDF Graph Normalization as the correct
approach to the problem, then we throw our hands up because the
problem is more complicated than we want it to be.
Manu Sporny: skolem id:S is not a solution to this probglem
David Booth: this is not true; it is a solved problem, based on
the well known suffixes
Manu Sporny: if you control the domain, yes
... in that case, we cannot say that there is a specific
domain space for thi
... if your system doesn't understand bnodes in these
positions, you need a callback to provide a skolem id which is
unique to your system
David Booth: and use that well-known suffix, so that it is
predictably recognized
Markus Lanthaler: isn't that what we are currently saying in the
spec?
Manu Sporny: it's not in the API
Markus Lanthaler: but the algorithm spec says this [correct?]
David Booth: my point is that it should say MUST replace them
David Booth: there is no RDF system which supports this
... the point is strict alignment
... if one person takes a JSON-LD document and serialize it
into Turtle, and another person does the same, the result is
essentially the same
... there is a difference between the JSON-LD blank node and
RDF blank node
Markus Lanthaler: but you can use it in the object position and
the graph id position at the same time
Gregg Kellogg: but since the graph id does not denote the graph,
it's semantically not a problem
... in practise though, it would be
... the dictum should be that if a blank node is converted
(skolemized) – *all* identifiers must be changed accordinly
Markus Lanthaler: so a skolemized iri is a bnode?
David Booth: no
David Booth: yes, it is a hack to make it work around a
shortcoming in the RDF model
David Booth: this is only for people wanting to interpret this
as RDF
Dave Longley: using graph normalization to compare this
regardless of syntax, this can be a prblem
... the skolemization of (certain) bnodes makes the
normalization complex
David Booth: Yes, the normalization algorithm may need to know
about the well-known IRI suffixes.
Sandro Hawke: a gen-id is not a blank node. it's complex and
annoying, but useful.
Markus Lanthaler: would like to quickly resolve this:
https://github.com/json-ld/json-ld.org/issues/257
David Booth: it is a shortcoming which is nowhere near going
away, so it should he handled
Sandro Hawke: we need to check with the RDF concepts and see if
it says what we need
David Booth: so, postpone and discuss more with the RDF WG?
Manu Sporny: yes
Markus Lanthaler:
https://github.com/json-ld/json-ld.org/issues/257#issuecomment-19169738
Markus Lanthaler: maybe we can resolve this directly in the issue
tracker, the datatype issue:
https://github.com/json-ld/json-ld.org/issues/257#issuecomment-19169738
Markus Lanthaler: should be easy to resolve that
Manu Sporny: ah right, let's try to resolve via issue tracker,
then do a proposal next week
-- manu
--
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/
Received on Tuesday, 11 June 2013 16:44:14 UTC