W3C home > Mailing lists > Public > public-rdf-wg@w3.org > May 2012

RDF WG minutes for 2012-05-30

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Wed, 30 May 2012 13:03:18 -0400
Message-ID: <4FC652D6.7090109@digitalbazaar.com>
To: RDF WG <public-rdf-wg@w3.org>
The cleaned minutes from today's telecon are available here:


RDF Working Group Teleconference

Minutes of 30 May 2012

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

   Manu Sporny, Richard Cyganiak

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

1. Minutes from Last Meeting
2. Next Meeting
3. Turtle Last Call
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: 

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!


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


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.




(Scribe set to Richard Cyganiak)

Manu Sporny: proposal to publish JSON-LD as FPWD is here: 

... some RDF-WG members joined the previous JSON-LD call to discuss some 

... 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 
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, 

... 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 
... comparing rdfa and json-ld, they have received similar amount of input

Gregg Kellogg: 
... 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 

Ivan Herman: the documents should physically move into the WG's hg 

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 
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 

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 

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 

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 

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> 
"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
Received on Wednesday, 30 May 2012 17:04:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:02:05 UTC