- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Wed, 30 May 2012 13:03:18 -0400
- To: RDF WG <public-rdf-wg@w3.org>
The cleaned minutes from today's telecon are available here:
http://www.w3.org/2011/rdf-wg/meeting/2012-05-30
RDF Working Group Teleconference
Minutes of 30 May 2012
Seen
Alex Hall, Andy Seaborne, Antoine Zimmermann, David Wood, Eric
Prud'hommeaux, Gavin Carothers, Gregg Kellogg, Guus Schreiber, Ivan
Herman, Lee Feigenbaum, Manu Sporny, Patrick Hayes, Peter
Patel-Schneider, Pierre-Antoine Champin, Richard Cyganiak, Sandro Hawke,
Steve Harris, Ted Thibodeau, Thomas Baker, Zhe Wu
Scribe
Manu Sporny, Richard Cyganiak
Resolutions
1. Accept the minutes of the 23 May telecon.
2. RDF-WG to publish JSON-LD syntax spec, and stripped-down version of
JSON-LD API spec with framing and normalization removed, as FPWD,
with intention to go on recommendation track
Topics
1. Minutes from Last Meeting
2. Next Meeting
3. Turtle Last Call
4. JSON-LD
5. RDF spaces draft
(Scribe set to Manu Sporny)
1. Minutes from Last Meeting
Richard Cyganiak: http://www.w3.org/2011/rdf-wg/meeting/2012-05-23
Guus Schreiber: Here they are:
http://www.w3.org/2011/rdf-wg/meeting/2012-05-23
PROPOSED: Accept the minutes of the 23 May telecon.
David Wood: Errors in the minutes... should fix those before we accept them.
Peter Patel-Schneider: The only problem with the minutes appears to be a
confusion about who Tony is.
Guus Schreiber: These are not big issues in the minutes, happy to take
an action to fix them.
Richard Cyganiak: +1
RESOLVED: Accept the minutes of the 23 May telecon.
Peter Patel-Schneider: +1
No objections for resolving minutes.
Guus looking at action items to see if we can get rid of anything...
David Wood: I went through all the folks that attended telecons, only
pulled scribes who showed up in 2012.
Guus Schreiber: Welcome Gregg Kellogg!
Richard Cyganiak: welcome gkellogg!
Guus Schreiber: Virtual round of applause for Peter, who just became an
IEEE Fellow!
*clapping*
Guus Schreiber: Richard, claiming victory on your two actions? 173 174?
Richard Cyganiak: Yes, conformance section for TURTLE is good. Second
action - wrote mail to Yves, but didn't get a response yet.
Guus Schreiber: Yes, but you did the action... so that's good.
2. Next Meeting
Guus Schreiber: Next week is SemTech 2012 - I'm not available for
chairing. Let's skip next week.
David Wood: I concur.
No objections... resolved that next telecon is June 13th 2012.
3. Turtle Last Call
http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/index.html
Guus Schreiber: Is there additional action on this needed?
Gavin Carothers: Nothing to raise as an issue, it's not quite done.
Guus Schreiber: You get one more week since SemTech 2012 is next week.
We'll schedule TURTLE LC decision until June 13th 2012. But nothing to
discuss now, right?
Pierre-Antoine Champin: q+ about reviewing turtle
Pierre-Antoine Champin: q+ to ask about reviewing turtle
Gavin Carothers: There is a recurring discussion on should we have the
Turtle family of languages?
Pierre-Antoine Champin: I have a pending action to review the Turtle
document - I've been told to wait until some mods are done. I may have
missed something, but I haven't been prompted to review yet. Should I do
it before next meeting?
Guus Schreiber: I think the documents have plenty of review - you could
do a check at this point.
Guus Schreiber: Editor's are doing final editorial changes now.
Pierre-Antoine Champin: Sorry I missed the opportunity, I will do a
check on the documents.
Guus Schreiber: Ok, we're fine to go ahead then, Gavin.
4. JSON-LD
http://lists.w3.org/Archives/Public/public-rdf-comments/2012May/0070.html
http://lists.w3.org/Archives/Public/public-rdf-wg/2012May/0635.html
(Scribe set to Richard Cyganiak)
Manu Sporny: proposal to publish JSON-LD as FPWD is here:
http://lists.w3.org/Archives/Public/public-rdf-wg/2012May/0635.html
... some RDF-WG members joined the previous JSON-LD call to discuss some
issues
... such as, what spec should the to/from-RDF-algorithm go, should the
API spec go to W3C or not, should experimental stuff go in or not
... i feel we got consensus
... i'd like to summarize main points
... 1. should JSON-LD terminology be made more in line with RDF
concepts? we think yes where it makes sense, but there are some minor
corner cases where we feel our terminology is more appropriate. this
shouldn't block FPWD
Gavin Carothers: Yes.
Gavin Carothers: It should be in the document
Gavin Carothers: So that the public knows
Eric Prud'hommeaux: is it worth noting that in the document?
Gavin Carothers: <p class="issue"></p>
Manu Sporny: we have it documented it in various places, minutes etc
Eric Prud'hommeaux: an issue marker in the doc would be great
Manu Sporny: https://github.com/json-ld/json-ld.org/issues/127
David Wood: also note that rdf-concepts is still a somewhat moving target
Manu Sporny: 2. we think the RDF-WG should also publish the JSON-LD API
spec because it has the algorithms for converting to and from RDF
... these algorithms are in the JSON-LD API spec at the moment
... we could have lifted the algorithms from the spec, but this would be
weird editorially
Zakim IRC Bot: pchampin, you wanted to ask about reviewing turtle
... another option would be to have the conversion algorithm in its own
separate document, but concluded that the API spec is fine as it is;
just remove some experimental bits
Eric Prud'hommeaux: i added a comment at the botton of
<https://github.com/json-ld/json-ld.org/issues/127#issuecomment-6012736>
saying "In a prominent place in the FPWD, document the intention to
align with the RDF model and terminology. This will calm the RDF
community and reduce the comments requesting something you already plan
to do."
... an open question is: can the RDF-WG publish an API spec for JSON-LD,
charter-wise?
... we think yes because it supports the syntax spec; they go together
and complement one another
Patrick Hayes: Sorry Im late, and IRC only.
... so baring objections from W3C members we think it should be ok
Manu Sporny: 3. having established that RDF-WG *can* publish JSON-LD
API, *should* it do it?
... we need to pull some bits out of the spec
... graph normalization is already moved into its own separate document
... and we'll also remove framing
... because these are experimental features; the rest is stable enough
for FPWD
... so in summary we think RDF-WG should publish JSON-LD API as this
pulls in the normative conversion, and is a useful spec
4. should we move the to/from-RDF stuff into separate document?
Manu Sporny: 4. should we move the to/from-RDF stuff into separate document?
... no, no need to
Manu Sporny: 5. how to do the handover of JSON-LD specs from the
community group to RDF-WG
... there's W3C process for that
... so a hand-off can be done once RDF-WG has made a decision
Gavin Carothers: +q assignment of editors for JSON-LD in the WG
... once the hand-off is done, RDF-WG is in charge of the docs and the
CG can't change it any more
Gavin Carothers: +q to ask about assignment of editors for JSON-LD in the WG
... this entails copyright and patent stuff etc
Andy Seaborne: q+ to ask about handoff point @LC? @CR?
Manu Sporny: so the proposal is that RDF-WG publish JSON-LD syntax spec
*and* stripped-down version of JSON-LD API spec with framing and
normalization removed, as FPWD
David Wood: q+ to ask about number of implementations
Zakim IRC Bot: gavinc, you wanted to ask about assignment of editors for
JSON-LD in the WG
Zakim IRC Bot: AndyS, you wanted to ask about handoff point @LC? @CR?
Andy Seaborne: what state would documents be in after the hand-off?
Manu Sporny: FPWD. the community group says "we are done with these
documents", and the WG pulls them in as FPWDs
... it's up to the WG to decide how quickly the docs can go to LC
Guus Schreiber: whether they are rec track is still a separate decision
Manu Sporny: the CG would have an issue handing off the documents if
RDF-WG doesn't take them to REC. CG would likely try to find another
venue in that case
Andy Seaborne: hoping that CG would continue to be involved all the way
to REC
Zakim IRC Bot: davidwood, you wanted to ask about number of implementations
Gavin Carothers: +q to ask about assignment of editors for JSON-LD in the WG
Manu Sporny: yes that's the plan. that's why gkellogg is joining and the
other editors will become invited experts
Gregg Kellogg: Immplementations link here: http://json-ld.org/
Manu Sporny: there are (numerous implementations)
... six implementationsj
Eric Prud'hommeaux: i might have written a parser too. i forget.
Ivan Herman: i have JSON-LD output in my RDFa impl
Zakim IRC Bot: gavinc, you wanted to ask about assignment of editors for
JSON-LD in the WG
Gavin Carothers: do we get editors assigned to the JSON-LD docs before FPWD?
Manu Sporny: when the group decides to take the docs on as rec track
work, the current editors will join RDF-WG
Eric Prud'hommeaux: +1 to rec track
Pierre-Antoine Champin: +1 to rec track
Guus Schreiber: opinions on taking JSON-LD on rec track?
Gregg Kellogg: +1
Manu Sporny: +1 to rec track (fwiw)
... JSOn syntax in the charter
Patrick Hayes: +1
Sandro Hawke: +0.5 I'm nervous about the lack of breadth of input
Gavin Carothers: +0 (TQ non opinion) +1 (LexMachina opinion which I
can't have until July)
David Wood: what was the plan re the RDF algorithm, can't recall
Patrick Hayes: Gavin is a quantum superposition.
Andy Seaborne: 0 (I can't promise my time to it so don't feel I can +1)
-- moral +1 to JSON-LD/RDF core parts
Ivan Herman: we talked about possibly publishing the JSON-LD group's
graph normalization algorithm separately as a note
David Wood: +1
Zhe Wu: +0
Manu Sporny: q+ to explain the breadth of review.
Sandro Hawke: JSON-LD is the product of a small group of people. it's in
our charter, so the world was put on notice, but i think not all people
who are concerned about this are involved
Gavin Carothers: FPWD will need a lot of review
... if we don't get the right people involved in reviewing, it would be
a problem
... don't want it to go to rec just because a few people like it and the
rest don't pay attention
... can we get enough people who know what a good json api looks like to
review this?
Manu Sporny: to be clear, there were four editors, but the spec has been
passed by a number of other communities
... markus has a list of users
Zakim IRC Bot: manu1, you wanted to explain the breadth of review.
... you could say that for any spec. there's not just the people who
show up to the telcos
... it has had more review than ppl in RDF-WG may think
Guus Schreiber: it would be good if that was visible from the documents
Sandro Hawke: that could be mentioned in the status section of the document
Sandro Hawke: best to start maintinaing an Implement Report page.
Sandro Hawke: best to start maintinaing an Implementation Report page.
Gregg Kellogg: dbpedia has json-ld format output for example
Manu Sporny: Sandro, implementations are listed on the front page of
http://json-ld.org/
... comparing rdfa and json-ld, they have received similar amount of input
Gregg Kellogg:
http://www.slideshare.net/lanthaler/jsonld-for-restful-services
... btw i'm giving a talk at semtech on json-ld
... it includes list of implementations
Patrick Hayes: Richard, got a link to that talk? Slides?
PatH, http://www.slideshare.net/lanthaler/jsonld-for-restful-services
Patrick Hayes: Ta.
Guus Schreiber: it's important to get public comments on this entire issue
Richard Cyganiak: Guus, you said that you might want to be able to tell
if it's gotten more public feedback? [ Scribe Assist by Manu Sporny ]
Richard Cyganiak: Sandro already mentioned that it might go into the
status of the document section - even though this is a FPWD, it already
has an 18-month history elsewhere. [ Scribe Assist by Manu Sporny ]
Richard Cyganiak: We should state this clearly in the status section. [
Scribe Assist by Manu Sporny ]
Manu Sporny: we have a number of document cleanup issues, i'll add it there
PROPOSED: RDF-WG to publish JSON-LD syntax spec, and stripped-down
version of JSON-LD API spec with framing and normalization removed, as
FPWD, with intention to go on recommendation track
Manu Sporny: +1
Patrick Hayes: +1
Gregg Kellogg: +1
Peter Patel-Schneider: +1
Richard Cyganiak: +1
Zhe Wu: +0
Guus Schreiber: +1
Alex Hall: +1
Pierre-Antoine Champin: +1
David Wood: +1
Sandro Hawke: +1
Eric Prud'hommeaux: +1
Gavin Carothers: +0 (TQ) +1 (LexMachina non Member)
Ivan Herman: +1
RESOLVED: RDF-WG to publish JSON-LD syntax spec, and stripped-down
version of JSON-LD API spec with framing and normalization removed, as
FPWD, with intention to go on recommendation track
Thomas Baker: +0
Guus Schreiber: i think this will be very useful output for this group
Manu Sporny: we will go back and apply all the changes we said
... we'll get the CG to sign off on those documents
... and then put them into W3C FPWD format and give them to the group
Guus Schreiber: then there'll be a two-week review period before FPWD
Manu Sporny: i guess we should pull the trigger and get started on the
transition
Ivan Herman: the documents should physically move into the WG's hg
repository
Guus Schreiber: manu, you and gkellogg are WG members now. is markus the
other critical person?
Gregg Kellogg: I'd suggest niklasl as well.
Manu Sporny: yes; our CEO has also worked on a lot of the algorithms but
may not be necessary to make him WG member
Gregg Kellogg: niklasl is very vocal and has given good input too
Guus Schreiber: does markus work for a W3C member?
... needs to be worked out
... manu, are you familiar with our hg repository?
Manu Sporny: there are some technical issues there but we'll iron those out
Eric Prud'hommeaux: i'm not convinced that it's worth making manu copy
this across
Eric Prud'hommeaux: (and keep it in sync)
Richard Cyganiak: I don't think it makes much sense to move it to W3C -
as long as it's in a public repo, you can make your own copy and modify
it. [ Scribe Assist by Manu Sporny ]
Richard Cyganiak: I don't have an objection with moving into mercurial
repository - it's a process point, not a point of making sure everyone
has adequate access - that's already true with github. [ Scribe Assist
by Manu Sporny ]
Andy Seaborne: On IP and copyright front, surely move to W3C is cleaner.
Guus Schreiber: it's good for clarity if everyting is in the same place
Andy Seaborne: (its work though :-()
Manu Sporny: +1 to AndyS - that's the strongest point, imho.
Pierre-Antoine Champin: I guess the changes on mercurial could be
mirrored on github if we want
Guus Schreiber: thanks manu and gregg for bringing this to the WG
... are there potential reviewers?
(Scribe set to Manu Sporny)
Richard Cyganiak: ... timeframe second part of june, early july
Eric Prud'hommeaux: I'd want to do a review.
Andy Seaborne: I'd be interested...
Pierre-Antoine Champin: I'd be interested if time at the time in reviewing.
Guus Schreiber: We have 3 reviewers, that's good news.
5. RDF spaces draft
Guus Schreiber: Should we discuss this document yet?
Sandro Hawke: Probably a good as time as any to discuss it...
Sandro Hawke: We may want to look at some of the other issues that we
may have consensus on.
Guus Schreiber: Given the time, I'd prefer to do this on June 13th.
Richard Cyganiak: I think it might be useful to look at where we are
from a high-level POV regarding the Graphs discussion. We have made some
progress consolidating this fluid design space a bit.
Sandro Hawke: all the GRAPHS issues
http://www.w3.org/2011/rdf-wg/track/products/1
Richard Cyganiak: There are 3 open questions that can be treated
separately - one of them is the terminology question - should we call
this Graph Containers, Spaces, Stateful Resources, etc.
Eric Prud'hommeaux: +1 to graph space container resources
Guus Schreiber: +1 on the consensus on basic structure
Patrick Hayes: I suggest putting terminology last.
Richard Cyganiak: Despite a lot of disagreement, we seem to be talking
about the same basic structure - it's mostly a matter of finding
terms/definitions.
Guus Schreiber: +1 to Pat
Richard Cyganiak: The second thing is the semantics - what we need to
define about it to give it formal semantics - the good news is that we
have a couple of proposals on the table.
Richard Cyganiak: There are a number of sketches on how to do this... we
may be able to work out what the options are from those.
Patrick Hayes: I don't see the convergence of ideas that Richard
apparently sees. NOt yet, anyway.
Ted Thibodeau: ericP - I think you meant "stateful graph data space
container resources"
Richard Cyganiak: The third part is the syntax - seems like there are
quite a number of open questions there - still lots of things to be
talked about. We should clarify the open questions - the decisions that
need to be made. N-Quads, TRiG, etc. We can treat these questions
separately. Not everyone is interested in each of those discussions - we
can have them in parallel.
Guus Schreiber: In the third part, you really meant syntax?
Lee Feigenbaum: There are significant proposals for combining Turtle + TriG
Guus Schreiber: We never really seem to want a new syntax - proposals
for adding a few RDF Classes or properties - not addition of new syntax, no?
Lee Feigenbaum: that sort of thing
Gavin Carothers: There are very large number of details ;)
Patrick Hayes: +1 to separation of semantics and syntax.
Richard Cyganiak: There is a question on whether N-Quads or TRiG should
just be an extra feature for Turtle - not radical new proposals, but
still questions that need to be answered.
Sandro Hawke: The most pointed concern is that TRiG is disjoint from
Turtle - I think it's important to make curly braces optional, not a
trivial syntax point at all.
Sandro Hawke: We made some progress with g-* terminology - maybe we
should use that?
Sandro Hawke: graph, graphState, containsGraph
Guus Schreiber: We should keep to placeholder terminology...
Sandro Hawke: containTriples
Sandro Hawke: g-rel
Richard Cyganiak: g-rel +1
Richard Cyganiak: also useful: g-pair
Ted Thibodeau: g-rel, g-rev ? but which is which?
Discussion about terminology
Patrick Hayes: Might be best to avoid the "contain" metaphor. We could
just say hasGraph, hasTriples, etc..
Zhe Wu: go to jump to another meeting.
Zhe Wu: bye guys
Thomas Baker: +1 g-relation
Andy Seaborne: Is there one fixed relationship? Major decision.
Sandro Hawke: We want to get this temporary terminology correct so we
don't get confused about it.
Sandro Hawke: I like g-contains
Pierre-Antoine Champin: was about to propose g-state
Eric Prud'hommeaux: gbox2gstate
Richard Cyganiak: then g-state
Eric Prud'hommeaux: gbox2gbox
Eric Prud'hommeaux: gbox2gsnap rather
Patrick Hayes: Reading this on IRC, I am g-confused.
Sandro Hawke: We are talking about the relationship between a gBox and a
gSnap....
Patrick Hayes: Ah, OK.
Andy Seaborne: This gets back to trying to sort out semantics... we are
going down a particular route here - there is another level of
indirection here.
Patrick Hayes: Its really between a gBox and a gSnap *and a time*.
Richard Cyganiak: PatH +1
Andy Seaborne: The various different ways and use cases we've seen say
that we're constraining this.
Patrick Hayes: Or more generally a particular set of circumstances
defining an access event.
Sandro Hawke: Sounds like we don't even have consensus about this point.
Eric Prud'hommeaux: i agree that there is a description of the use in
addition to the mapping from gbox to gsnap
Richard Cyganiak: q+ to say this is why i tried to argue against g-box
Andy Seaborne: The relationship between the URI and the graph has at one
point... two steps... degree of flexibility for use cases. If we were
flexible, that's what a gBox is... by going down to terminology now, we
might be covering up an important discussion.
Sandro Hawke: Are you suggesting we can't have a placeholder?
Andy Seaborne: Depends on what that placeholder is doing.
Sandro Hawke: Placeholder for the name between the gBox and gSnap - what
it has to do with the Web is not clear.
Richard Cyganiak: This thing that we're talking about right now - is
there really just one relationship - or does a different use case have a
different relationship. This container metaphor with gBox is not such a
good idea - it's stifling, makes it hard to think about this in terms
that are sufficiently flexible.
Zakim IRC Bot: cygri, you wanted to say this is why i tried to argue
against g-box
Richard Cyganiak: I propose we say: Yes, there is only a single
relationship - but we should put very little constraints on what could
be a gBox. If any resource can be a gBox, then it's okay to have a
single relationship to the gSnap because the flexibility is already in
the fact that the graph IRI can be used to name anything.
Ted Thibodeau: saying "anything can be a gbox" seems like saying
"anything can be a milk carton"... and that's not the case
Guus Schreiber: +1 to take this flexible view on what g-box stands for
Richard Cyganiak: I think a single relationship is enough - if we don't
take the gBox too literally, something very wide - then we're good (maybe)
Guus Schreiber: I agree fully with the "flexible" point of view - taking
all of this flexibility into account when trying to explain it, makes it
more complex to outsiders. gBox may not always be the right metaphor.
Guus Schreiber: Suggest to go for g-relation, could be multiple
Pierre-Antoine Champin: I'm not sure I understand your point, Richard.
If a gBox is restrained to be something very specific - a placeholder
containing one graph at one point in time, when that might be okay. If
you want to say that it's more flexible, there can be many possible
relations between gBox to gSNap. I'd have exactly the opposite reasoning
that you proposed.
Guus Schreiber: because of simplicity
Richard Cyganiak: The flexibility is needed because one of the things
that we need to be able to express in this abstract syntax is SPARQL. We
can already associated an IRI with a graph - there are no constraints on
the graph name.
q+ to discuss JSON-LD named graphs and what IRI identifies.
Richard Cyganiak: This flexibility needs to be in the model as well.
Richard Cyganiak: This may be better done in written form than in
discussion.
Pierre-Antoine Champin: You consider the URI as a part of the gBox...
but I don't consider the URI as a part of the gBox.
Patrick Hayes: We can get into g-box metaphysics and never get back out.
Semantic lesson is, it doesnt matter unless it affects a truthvalue of
some triple.
Sandro Hawke: q+ to talk about the person-as-graph-name use case
Richard Cyganiak: as long as we don't take a strong stance on what the
IRI denotes, we're good. If we say the IRI denotes a gBox, then that
sounds fine, but it's difficult to see how an IRI can denote a person.
Pierre-Antoine Champin: thanks Richard, it makes more sense to me now
Sandro Hawke: can we adjourn the meeting and graph people stay on and chat.
Guus Schreiber: We don't have a placeholder name for the relationship.
Guus Schreiber: meeting adjourned.
Ted Thibodeau: q+ to suggest that SPARQL is actually
(quantumly?)addressing gSnaps, not gBoxes, even if the gSnap is
transient and not properly named\
Patrick Hayes: I like the metaphor of a "source" or "emitter" of RDF
rather than a container. For example, a human being can emit RDF from
time to time. No problem with that.
Patrick Hayes: Oh, sorry, is everyone leaving?
Patrick Hayes: Bye guys.
Guus Schreiber: not yet, Pat
Patrick Hayes: OK
David Wood: We are staying after to discuss graphs...
Sandro Hawke: Richard, I think maybe that an interesting point is what
we should do about folks who want to use URI of a person as the graph
label in SPARQL. We agree that people do that, and the question is
whether that is a reasonable thing to do or we say that is forbidden.
Sandro Hawke: I don't think we can forbid this... I think I'm more
towards saying it's not okay... if you do that, you should keep that to
yourself.
Richard Cyganiak: I agree that the most important thing is that it works
well for the Webby case - where yo uhave a URI, you dereference, you
have triples and that's the graph that is associated with the URI.
Richard Cyganiak: I'm perfectly happy with saying that you shouldn't use
the gRelation pattern.
Richard Cyganiak: if you find a dataset out there in the wild, then if
you don't have any additional evidence to the contrary, then you should
assume that's the type of relationship that's in there.
Pierre-Antoine Champin: I'm still interested, but I have to go too; sorry
Richard Cyganiak: We really don't have to forbid anything at all - we
don't want to make it illegal... you can do it and nothing breaks.
Patrick Hayes: FWIW, semantics never makes anything illegal :-)
Zakim IRC Bot: sandro, you wanted to talk about the person-as-graph-name
use case
Richard Cyganiak: The main question is the terminology that we use - how
well does it work with the corner cases that we're using?
Guus Schreiber: I need to leave, but wonder where we give the advice how
to give an identifier to a person
Richard Cyganiak: Does it help or does it hurt - the terminology?
Richard Cyganiak: The most important thing is that it works well for the
Web case... we shouldn't say "MUST NOT".
Sandro Hawke: Are you okay with saying SHOULD NOT?
Sandro Hawke: ("in public")
Richard Cyganiak: if you publish a dataset on the Web that has
dereferenceable graph names as URIs, then you should do the Webby thing.
Richard Cyganiak: If you publish a dataset on the web that has deref
URIs as graph names then you should do the webby thing [ Scribe Assist
by Sandro Hawke ]
Sandro Hawke: q+ to say it's not just deref URIs.
Ted Thibodeau: "signing graphs" means "signing gSnaps" -- it *has* to.
Ted Thibodeau: not gBoxes.
Patrick Hayes: Issue is not what publishers do, but what others do
downstream with those RDF sources.
Sandro Hawke: yes MacTed (or g-text)
Manu Sporny: we use named graphs for signatures in RDFa and JSON-LD.
It's problematic when the language (RDFa) doesn't support named graphs,
but still has to express a signature on a named graph. [ Scribe Assist
by Eric Prud'hommeaux ]
Eric Prud'hommeaux: ... we haven't said that it e.g. MUST include a
hash, timestamp, etc.
Patrick Hayes: A publishes some RDF with a Webby IRI this:one, then B
creates a dataset with that RDF associated with a uri that:one which
denotes a human being. NOt A's fault.
Patrick Hayes: And C says this:one owl:sameAs that:one
Andy Seaborne: +1 toPatH
Eric Prud'hommeaux: ... we use a subject identifier as a graph
identifier in signing, we don't see a way around this while staying flexible
Eric Prud'hommeaux: ... because RDFa will not have graph support for a
long time, this group should not limit how RDFa users can use graphs
Patrick Hayes: MacTed, couldnt we have a notion of a 'locked' (fixed)
g-box? And then sign that? Then there only has to be one kind of thing
(g-boxes) but some of them have a special status.
Eric Prud'hommeaux: ... <asset1> { <asset1> :price $22; }. <asset1>
signatureValue
"OGQzNGVkMzVmMmQ3ODIyOWM32MzQzNmExMgoYzI4ZDY3NjI4NTIyZTk=". <-- The
second statement applies to the graph, and is not data in the graph.
Ted Thibodeau: PatH - the 'locked' g-box *is* a g-snap
Ted Thibodeau: so a g-snap *might* be a subclass of g-box...
Patrick Hayes: No, its not. Sematnically its a lot easier if we keep one
category, even if they have several subclasses.
"@type": "GraphSignature2011",
"creator": "http://manu.sporny.org/webid#key-5",
"signatureValue": "OGQzNGVkMzVmMmQ3ODIyOWM32MzQzNmExMgoYzI4ZDY3NjI4NTIyZTk="
<asset1> sec:signature [ ... ];
Patrick Hayes: g-snap is what you get out of the g-box, in all cases.
When the box is 'locked', its the same snap every time. Guaranteed.
Eric Prud'hommeaux: what if you're selling a signature?
Ted Thibodeau: PatH - gBoxMutable, gBoxImmutable ?
Patrick Hayes: The old named-graphs paper had a lot of ideas about
secure signing in it, might be worth checking it out.
Patrick Hayes: Bizer & Carroll did it.
Patrick Hayes: MacTed, yes exactly.
Ted Thibodeau: with gBoxMutable, gSnap-time1 may differ from gSnap-time2
Ted Thibodeau: with gBoxImmutable, gSnap-time1 will always be (equal?
equivalent? identical modulo ordering?) to gSnap-time2
Patrick Hayes: I have to leave very soon.
Andy Seaborne: sounds like ETL in disguise
Richard Cyganiak: Maybe we don't need to take a position on whether or
something is a gBox - we could just say resources could have state.
Richard Cyganiak: What kind of thing could have state - could have
content - our model of the Web/World - anything can have an associated
graph state.
Sandro Hawke: I pretty much agree with that - how do we explain that to
the rest of the world - maybe no terminology would be best.
Ted Thibodeau: "resources can have state" -- essentially rephrases
"context lenses" through which to view a resource...
This revision (#1) generated 2012-05-30 17:00:25 UTC by 'msporny',
comments: 'Minor editorial fixes.'
-- manu
--
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: PaySwarm Website for Developers Launched
http://digitalbazaar.com/2012/02/22/new-payswarm-alpha/
Received on Wednesday, 30 May 2012 17:04:06 UTC