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

On Feb 18, 2013, at 1:13 PM, Andy Seaborne wrote:

> 
> 
> On 18/02/13 18:19, Markus Lanthaler wrote:
>> On Monday, February 18, 2013 7:01 PM, Andy Seaborne wrote:
>>> You, JSON-LD, can add the
>>> constraint that a bNode/IRI is actually referring to the graph.
>> 
>> if that's not standardized across all RDF dataset syntaxes you couldn't
>> transform the JSON-LD data to another syntax.
> 
> Hence my suggestion for using IRIs minted by the parser because you can define them to denote the graph.

How do you do this, Andy? How is this act of definition recorded? If I read a dataset somewhere on the Web and it has IRIs in it,  how would I know that they had been "defined" in this way so that I knew they were intended to denote a graph? All I have is the dataset (perhaps in the form of a document which parses to the dataset) and the RDF specifications: and the latter tell me that I *cannot* make this assumption. 

> You can then define the output of JSON-LD parsing that a graph label using one of these IRIs is denoting the graph.  owl:sameAs (except that's for "individuals"

Only in OWL-DL. Use Owl-Full and you are OK. :-)

> / "IRI").
> 
>>> (but then the graph is an abstract value - not the JSON-LD normalized
>>> structure, Turtle document or any specific bytes.  1, 01, +1 and all
>>> that).
>> 
>> Yes, I was always talking about the abstract construct and not the bits and
>> bytes on the wire.
>> 
>> 
>>>> If you have the following dataset:
>>>> 
>>>> {
>>>>    _:b1 x:signature "... signature ..." .
>>>> }
>>>> _:b1 {
>>>>    ... some triples ...
>>>> }
>>>> 
>>>> Do the two _:b1 above refer to the same, i.e., the named graph?
>>> 
>>> If you say they do, they do.  Ditto IRIs.
>> 
>> You mean the JSON-LD specification would have to say that?
>> 
>> 
>>>> RDF-CONCEPTS says:
>>>> 
>>>>     Despite the use of the word "name" in "named graph", the
>>>>     graph name does not formally denote the graph. It is merely
>>>>     syntactically paired with the graph. RDF does not place
>>>>     any formal restrictions on what resource the graph name may
>>>>     denote, nor on the relationship between that resource and the
>>>>     graph.
>>>> 
>>>> I read this as in the example above you wouldn't know to what the
>>> signature
>>>> applies. It may or may not be the graph. Manu's use case requires
>>> that it is
>>>>> 
>> 
> the graph to which the signature applies. That's the reason why I
>>> argued for
>>>> "bNodes MUST denote the graph".
>>> 
>>> You can add that as a requirement for JSON-LD (and that's true for
>>> bNodes or IRIs) - there is no need to make RDF adopt one position or
>>> the
>>> other, excluding the common current usages that we enumerated over the
>>> long discussions.
>> 
>> Really? Could you then still round-trip the data between different syntaxes
>> without changing its semantics?
> 
> Yes, round trip from JSON-LD-X -> TriG or NQuads -> JSON-LD, (where JSON-LD-X is the restriction of JSON-LD to RDF+Datasets - no Bnode or literal properties, etc)  It's just transcoding of the abstract data model and is neutral to semantics in graph labelling or IRI minting.

But the question arises, since this is 'neutral to semantics', whether the Trig/NQuads has the same meaning as the JSON-LD had. I think right now it does not. So the reverse mapping must be doing something that does not preserve meaning. So, although I don't follow the fine details, but I will bet you a good steak dinner that there will be some case where RDF-valid processing in the middle will break the reverse mapping to JSON-LD. 

Pat

> 
> 	Andy
> 
>> 
>> 
>> 
>> --
>> Markus Lanthaler
>> @markuslanthaler
>> 
> 
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Tuesday, 19 February 2013 04:28:17 UTC