Re: Slides for Berlin Data Workshop

On 2/27/19 4:19 AM, Antoine Zimmermann wrote:
> Sandro,
>
>
> In my opinion, this topic should not be debated in the JSON-LD group.
> It is of course appropriate for the N3 group though.
>
> Since you ask about graph metadata, I would never use RDF to describe
> RDF graphs. I would describe the files, or the information resources
> that encode RDF graphs. These things have a creator, a creation date,
> access rights, etc. RDF graphs (i.e. sets of RDF triples) are not
> created. They all are existing in the set of all RDF graphs at the
> same time.
>
> In this regard, the interpretation of Carroll et al. is superior: by
> interpreting the graph name as the named graph pair, you can
> distinguish the creation dates of two graph-encodings:
>
> <#mygrah> dc:created "2019-02-26T16:53:42+01:00"^^xsd:dateTime .
> <#yourgrah> dc:created "1999-01-01T00:00:00Z"^^xsd:dateTime .
> <#mygraph> { <timbl> a <Person> }
> <#yourgraph> { <timbl> a <Person> }
>
> If <#mygraph> and <#yourgraph> are interpreted as the graph "{<timbl>
> a <Person>}", then this graph has 2 creation dates, which is probably
> not what you want with your metadata.
>
>
> Best,
> --AZ


+1


Kingsley

>
>
> Le 26/02/2019 à 14:39, Sandro Hawke a écrit :
>> On 2/26/19 4:49 AM, Antoine Zimmermann wrote:
>>> Hello,
>>>
>>>
>>> This is my first email to the JSON-LD CG mailing list, so let me
>>> introduce myself: I am Antoine, working on semantic web technologies
>>> since 2004 as a researcher. I participated in the RDF 1.1 working
>>> group, quite actively, where my primary interest was RDF semantics.
>>>
>>> Concerning your slides, Gregg, on slide 2, you say "The only
>>> reasonable interpretation of graphs named via blank node (...) is
>>> that the blank node denotes the graph it names".
>>>
>>> Graph names can be interpreted in many ways, lots of which are
>>> considered reasonable by those who advocate them.
>>>
>>
>> This is a potentially large topic.  Perhaps we can take it to
>> github?  I wrote up this exact issue (in the context of the N3 CG),
>> at https://github.com/w3c/N3/issues/1, so that's probably a good
>> place to do it.
>>
>> Gregg is advocating for Option 2, which I think has a lot of merit,
>> although I agree it's not "the only reasonable interpretation".  I'd
>> love to hear how you propose to, for example, publish graph metadata,
>> Antoine.
>>
>> I separated the logic question out to
>> https://github.com/w3c/N3/issues/2, since I think it's
>> distinguishable. My current applications (credibility/disinformation)
>> are about provenance not about representing rules, so issue 1 is much
>> more important to me right now.
>>
>>    -- Sandro
>>
>>
>>> In fact, the very people who introduced the concept of named graphs
>>> (Carroll et al. in 2004) defined a formal semantics according to
>>> which an RDF interpretation I satisfies ("conforms to", in their
>>> words) a named graph (n,g) iff I(n) = (n,g), that is, the name is
>>> interpreted as the named graph *pair*, not the graph.
>>>
>>> Many people have used the idea of quads (that can be seen as a
>>> syntactic variation of the concept of named graphs) in very
>>> different ways, some of which are implemented in triple stores
>>> (e.g., spatio-temporal triple store Strabon).
>>>
>>> In any case, defining the meaning of a JSON-LD document is not part
>>> of the JSON-LD group's mission. JSON-LD defines how to map a
>>> JSON-based format to the abstract RDF structures, then people
>>> interpret it as they want, possibly following other specs like RDF
>>> Semantics, OWL, SWRL, or N3logic.
>>>
>>> Similarly, slide 5 is not about "Reasoning in JSON-LD": it is
>>> explaining how to map N3 formulas to JSON-LD. Then people can decide
>>> to interpret JSON-LD documents as N3, following slide 5
>>> representation, and do *N3 reasoning*, not "JSON-LD reasoning". They
>>> could also just map this representation to a normal RDF dataset and
>>> apply other kinds of reasoning.
>>>
>>>
>>> Best,
>>> --AZ
>>>
>>> Le 23/02/2019 à 23:50, Gregg Kellogg a écrit :
>>>> The format for the Berlin Data Workshop [1] remains unclear, but
>>>> I’ve prepared just a couple of slides to describe one way in which
>>>> Anonymous Named Graphs in JSON-LD could support the property graph
>>>> use case.
>>>>
>>>>> https://json-ld.org/presentations/JSON-LD-Support-for-Property-Graphs/
>>>>> <https://json-ld.org/presentations/JSON-LD-Support-for-Property-Graphs/>
>>>>>
>>>>
>>>>
>>>> There’s a short overview of new things in JSON-LD 1.1, and as a
>>>> bonus, a sketch of how Notation3 reasoning might look in JSON-LD.
>>>> (Hint, we really only need to invent a way to describe universal
>>>> variables at the syntax level; reasoning should be universal based
>>>> on obvious projections from Notation 3. The required extensions to
>>>> RDF Datasets and better description of reasoning semantics are work
>>>> to be done elsewhere).
>>>>
>>>> Gregg Kellogg
>>>> gregg@greggkellogg.net
>>>>
>>>>
>>>> [1] https://www.w3.org/Data/events/data-ws-2019/schedule.html
>>>>
>>>>
>>>
>>
>>
>

-- 
Regards,

Kingsley Idehen       
Founder & CEO 
OpenLink Software   
Home Page: http://www.openlinksw.com
Community Support: https://community.openlinksw.com
Weblogs (Blogs):
Company Blog: https://medium.com/openlink-software-blog
Virtuoso Blog: https://medium.com/virtuoso-blog
Data Access Drivers Blog: https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers

Personal Weblogs (Blogs):
Medium Blog: https://medium.com/@kidehen
Legacy Blogs: http://www.openlinksw.com/blog/~kidehen/
              http://kidehen.blogspot.com

Profile Pages:
Pinterest: https://www.pinterest.com/kidehen/
Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen
Twitter: https://twitter.com/kidehen
Google+: https://plus.google.com/+KingsleyIdehen/about
LinkedIn: http://www.linkedin.com/in/kidehen

Web Identities (WebID):
Personal: http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i
        : http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this