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

On 19/02/13 04:27, Pat Hayes wrote:
>
> 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?

The IRI being minted is under the control of the JSON-LD spec - it gets 
to define its meaning.

> How is this act of definition recorded?

I suggest in the default graph.  But Manu suggests that being under 
control of JSON-LD is enough.

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

Either know the provenance of the data or look at the URI pattern and 
know it's JSON-LD generated.

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

Markus was asking about a round-trip between syntaxes of a dataset, not 
the more general changing the dataset en route.

	Andy

>
> 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 15:11:12 UTC