Re: Problem with auto-generated fragment IDs for graph names

On 20/02/13 11:48, Souripriya Das wrote:
> Andy,
>
> You said: "which becomes something in RDF.  We discussing what."
>
> What would be (the currently most popular) proposed RDF translation
> for that JSON-LD array of graphs in your example?
>
> Thanks, - Souri.


If it were taken at face value, then like TriG, they would be default
graphs and be unioned together.  Multiple uses of the default graph or
of a graph label union together in TriG.

We (all) don't want that to happen here.  The aim is to have separate
graphs, with a convenient syntax for JSON-LD authors/publishers.  So
some kind of labelling with the labelling added automatically.

The most popular graph labelling is related to location, then related to
the primary topic of the graph.  From the communities that used
"context" for 4th slot (i.e. diving up a large graph into units),
literals like timestamps have been used.

I know of two systems that have used bnodes but neither of them in this 
way exactly.  One is no longer active (3Store - fair comment Steve?) and
one is N3/cwm, where they are distinguished in the system as graph
literals - you have have graph literals inside graph literals - there is 
no concept of quad or dataset.

My concerns are:

1/ This WG did not agree on dataset semantics earlier - making a
point-wise decision on the meaning of bNodes for graphs without the rest
of the semantics seems at risk of blocking other possibilities.

The obvious one to me is the extension of simple entailment rules se1
and se2 where IRIs can be replaced by bNodes.

Also, what are the implications of treating the bNode labelling as
closed or open?

2/ Lack of deployed experience of using bNodes in this particular way.
Using bNodes in a different way to IRIs is confusing.

3/ It is a value-judgement as to whether some of the alternative
suggestions are OK.

4/ In my experience, groups making late decisions, without properly
reopening the issue, does not tend to lead to good decisions.


JSON-LD isn't pure RDF anyway - see blank nodes as properties - and the
best we have is that RDF -> JSON-LD -> RDF is a lossless round trip and
that is preserved (I hope). A similar position here seems appropriate.

 Andy

> ----- Original Message ----- From: andy.seaborne@epimorphics.com To:
> wwaites@tardis.ed.ac.uk Cc: public-rdf-wg@w3.org Sent: Wednesday,
> February 20, 2013 6:21:45 AM GMT -05:00 US/Canada Eastern Subject:
> Re: Problem with auto-generated fragment IDs for graph names
>
>
>
> On 20/02/13 10:21, William Waites wrote:
>> On Wed, 20 Feb 2013 10:15:37 +0000, Andy Seaborne
>> <andy.seaborne@epimorphics.com> said:
>>
>>> I proposed the *parser* generate fragments or URIs and in fact
>>> label generation is what happens in your example ... _:c14n1,
>>> _:c14n2 which came from somewhere.  They are generated.  Use
>>> <#g1>, <#g2>.
>>
>> Are you seriously proposing that a parser for a serialisation
>> format for what is meant to represent RDF ought to mint URIs?
>>
>> That doesn't seem like an especially sound strategy to me. JSON-LD
>> should not be so special that it is radically different from the
>> other serialisations and goes so far as to actually *change* the
>> underlying RDF data...
>
> It's not changing the underlying RDF data.
>
> The input is JSON-LD syntax; the output is RDF quads.
>
> The input is a JSON array of graphs:
>
> [{ "@graph": { "source": "http://mybank.com/accounts/manu",
> "destination": "http://yourbank.com/accounts/richard", "amount":
> "5.00", "currency": "USD" } },{ "@graph": { "source":
> "http://mybank.com/accounts/manu", "destination":
> "http://yourbank.com/accounts/kingsley", "amount": "5.00",
> "currency": "USD" } }]
>
> which becomes something in RDF.  We discussing what.
>
> RDF/XML does it with rdf:li :-)
>
> Andy
>
>>
>> -w
>>
>
>

Received on Wednesday, 20 February 2013 13:15:53 UTC