Re: edge attributes in JSON-LD

On March 31, 2018 2:59:15 AM EDT, Ivan Herman <ivan@w3.org> wrote:
>Sandro, I do not have a problem with the quad/named-graph approach at
>all, and JSON-LD is o.k. with it. But the original request was on
>setting attributes to edges, which is a different ballgame…
>

Forgive my ignorance, but what's the difference between stating an attribute of an edge and a stating a property+value of a single-triple graph?   Aren't attributes and properties the same thing?  Aren't edges the same as graph arcs, which can be written down as spo triples?

I can imagine one formal difference which might arise in the case of duplicate or mutable edges, but actually the RDF named graph model handles that in the edge-attribute style (not the mathematical graph style), so again I'm not seeing a difference except that RDF puts the attribute on a set of edges instead of a single edge.  If you choose to only use singletons, I think it's the same.

What am I missing?

    - Sandro


>Ivan
>
>P.S. wary/weary… maybe it was an early morning Freudian slip :-)
>
>> On 31 Mar 2018, at 08:19, Sandro Hawke <sandro@w3.org
><mailto:sandro@w3.org>> wrote:
>> 
>> On 03/31/2018 01:04 AM, Ivan Herman wrote:
>>> 
>>> I would be very weary going down this line. We are indeed talking
>about, essentially, Property Graphs which is a different data model.
>>> 
>> 
>> I think you mean "wary", but "weary" is a pretty good fit too, I bet 
>:-)
>> 
>> I haven't studied "Property Graphs" to know what their data model is,
>but I think what's being proposed here is perfectly reasonable to do
>with quads/named-graphs.  I don't find the @graph syntax nearly as
>readable as some other syntaxes, but the semantics are the same, and
>they seem entirely sufficient to me.
>> 
>> Yes, I know formally the semantics aren't 100.00% defined, but I'm
>confident they are fine in practice. If you say graph1 is valid from t1
>to t2, and some triples are in graph1, it's obvious that you mean the
>conjunctions of those triples is valid (asserted, known to be true)
>from t1 to t2, and we don't really need some other formal spec to tell
>us that.  The one thing that's needed is the properties for
>valid-time-range. One could perhaps just use dc:temporal.
>> 
>>      -- Sandro
>>> The strength of JSON-LD is that it is a serialization of RDF,
>thereby creating a bridge towards Linked Data. It is not the vocation
>of JSON-LD to redefine the underlying RDF model; by doing so, JSON-LD
>would depart from that connection. Closing the gap between property
>graphs and RDF is a perfectly justifiable discussion to have. But this
>discussion should not happen around JSON-LD.
>>> 
>>> Note that there were some attempts a few years ago to start more
>serious work on that at W3C but it did not happen due to lack of
>interest; maybe things have changed and this could be looked into
>again.
>>> 
>>> Ivan
>>> 
>>> 
>>>> On 31 Mar 2018, at 01:17, Dan Brickley <danbri@danbri.org
><mailto:danbri@danbri.org>> wrote:
>>>> 
>>>> At Schema.org <http://schema.org/> we can't really claim Role has
>worked out well. I wouldn't advocate it for this.
>>>> 
>>>> It would be very interesting if a syntax could be found in JSON-LD
>1.1, alongwith an optional named graphs view of the data. This would
>help close the gap wth Property Graphs too.
>>>> 
>>>> Dan
>>>> 
>>>> On Sat, 31 Mar 2018, 00:06 karlg, <karl.geog@gmail.com
><mailto:karl.geog@gmail.com>> wrote:
>>>> Sub-classing schema.org <http://schema.org/> Role, e.g. with
>SettingRole seems promising, thanks
>>>> 
>>>> 
>>>> kg
>>>> 
>>>> 
>>>> {
>>>> 
>>>>   "@context": "http://linkedpasts.org/lp-context.jsonld
><http://linkedpasts.org/lp-context.jsonld>",
>>>> 
>>>>   "@type": "Place",
>>>> 
>>>>   "name": "Abingdon",
>>>> 
>>>>   “properties”: {“p1”: “___”, ...}
>>>> 
>>>>   "setting": [
>>>> 
>>>>     {
>>>> 
>>>>       "@type": "SettingRole",
>>>> 
>>>>       "setting": {
>>>> 
>>>>         "@type": "Place",
>>>> 
>>>>         "name": "Berkshire"
>>>> 
>>>>       },
>>>> 
>>>>       "startDate": "1600",
>>>> 
>>>>       "endYear": "1974"
>>>> 
>>>>     },
>>>> 
>>>>     {
>>>> 
>>>>       "@type": "SettingRole",
>>>> 
>>>>       "setting": {
>>>> 
>>>>         "@type": "Place",
>>>> 
>>>>         "name": "Oxfordshire"
>>>> 
>>>>       },
>>>> 
>>>>       "startDate": "1974",
>>>> 
>>>>       "endYear": "2018"
>>>> 
>>>>     }
>>>> 
>>>>   ]
>>>> 
>>>> }
>>>> 
>>>> 
>>>> On 3/30/18, 4:36 PM, "Gregg Kellogg" <gregg@greggkellogg.net
><mailto:gregg@greggkellogg.net>> wrote:
>>>> 
>>>> 
>>>> On Mar 30, 2018, at 3:09 PM, Karl Grossner <karl.geog@gmail.com
><mailto:karl.geog@gmail.com>> wrote:
>>>> 
>>>> 
>>>> Reopening this thread, as my current challenge relates closely:
>>>> 
>>>> I'm modeling historical Place attestations for gazetteer
>applications, and a potential linked.places JSON-LD modeling standard
>(a la linked.art). The idea is to build upon GeoJSON-LD.
>>>> 
>>>> Several attributes of Places are temporally indexed; i.e. may have
>a 'valid period', but are not amenable to event models in the same way
>as linked.art provenance is.
>>>> 
>>>> 
>>>> From what I can tell, three options are @graph, n-ary relations,
>and rdf:Statement reification. I've rendered some sample records below.
>My question is whether there has emerged a best practice for this
>general problem of edge attributes. Any comments welcome at this stage.
>I have been having a conversation with @gklyne on this, here, which may
>(?) shed further light.
>https://github.com/LinkedPasts/lp-network/issues/1
><https://github.com/LinkedPasts/lp-network/issues/1>
>>>> 
>>>> While we could probably add something to perform reification on
>expansion, or transformation to RDF, it’s not clear how that would
>allow you to make statements about the statement, and it’s widely
>considered an archaic mechanism. And, it would substantially complicate
>the already complex API algorithms.
>>>> 
>>>> 
>>>> The issue of edge attributes in JSON-LD is really no different than
>for RDF in general. While there is no syntax for automatic reification
>of statements, they can of course be represented in JSON-LD.
>>>> 
>>>> 
>>>> The RDF 1.1 position is more likely that named graphs can be used
>for this purpose, although there are no built-in semantics. (Basically,
>put the statement in a named graph, and then make other meta-statements
>with the graph name as a subject). Your approach 01 is essentially
>this.
>>>> 
>>>> 
>>>> Schema.org <http://schema.org/> takes another approach using the
>Role class (and sub-classes) [1], and this can be used in JSON-LD to
>describe information about relationships. This is what I’ve used in
>some of my own projects.
>>>> 
>>>> 
>>>> Gregg
>>>> 
>>>> 
>>>> [1] http://schema.org/Role <http://schema.org/Role>
>>>> 
>>>> 
>>>> 
>>>> thanks
>>>> 
>>>> --------
>>>> 
>>>> approach 01 (@graph; playground <https://tinyurl.com/y74p3pov> )
>>>> 
>>>> {
>>>>   "@context":
>"http://linkedpasts.org/assets/place-v4-context.jsonld
><http://linkedpasts.org/assets/place-v4-context.jsonld>",
>>>>   "related": [
>>>>     { "@id": "http://linkedpasts.org/graphs/01
><http://linkedpasts.org/graphs/01>",
>>>>       "@graph":
>{"@id":"myplace:Abingdon","part_of":"myplace:Berkshire"},
>>>>       "when": {
>>>>         "timespans":
>>>>             {
>>>>                       "earliestYear": "1600",
>>>>                       "latestYear": "1974",
>>>>                       "label": "from 17c. to 1974"
>>>>                     }
>>>>       }
>>>>     },
>>>>     { "@id": "http://linkedpasts.org/graphs/02
><http://linkedpasts.org/graphs/02>",
>>>>       "@graph": {"@id":"myplace:Abingdon",
>"part_of":"myplace:Oxfordshire"},
>>>>       "when": {
>>>>         "timespans":
>>>>             {
>>>>                       "earliestYear": "1974",
>>>>                       "latestYear": "2018",
>>>>                       "label": "from 1974"
>>>>                     }
>>>>       }
>>>>     },
>>>>     { "@id": "http://linkedpasts.org/graphs/03
><http://linkedpasts.org/graphs/03>",
>>>>       "@graph": {"@id":"myplace:Oxford",
>"part_of":"myplace:Oxfordshire"},
>>>>       "when": {
>>>>           "timespans":
>>>>             {
>>>>                       "earliestYear": "1000",
>>>>                       "latestYear": "2018",
>>>>                       "label": "from 11c."
>>>>                     }
>>>>             }
>>>>     }
>>>>   ]
>>>> }
>>>> 
>>>> 
>>>> approach 02 (per property graph example given in this thread)
>>>> 
>>>> [
>>>>     {"@id": "", "@type": "rdf:BoundDataset"},
>>>>     {"@id": "p1", "name": "Abingdon", "type": "settlement",
>"_:parent_p1p3":"p3", "_:parent_p1p4":"p4"},
>>>>     {"@id": "p2", "name": "Oxford", "type": "settlement",
>"_:parent_p2p4": "p4"},
>>>>     {"@id": "p3", "name": "Berkshire", "type": "county"},
>>>>     {"@id": "p4", "name": "Oxfordshire", "type": "county"},
>>>>     {    "@id": "_:parent_p1p3",
>>>>         "rdfs:subPropertyOf": "hasParent",
>>>>         "earliestYear": 1600,
>>>>         "latestYear": 1974,
>>>>         "label": "from 17c. until 1974"},
>>>>     {    "@id": "_:parent_p1p4",
>>>>         "rdfs:subPropertyOf": "hasPparent",
>>>>         "earliestYear": 1974,
>>>>         "latestYear": 2018,
>>>>         "label": "from 1974"},
>>>>     {    "@id": "_:parent_p2p4",
>>>>         "rdfs:subPropertyOf": "hasParent",
>>>>         "earliestYear": 1000,
>>>>         "latestYear": 2018,
>>>>         "label": "from 11c."}
>>>> ]
>>>> 
>>>> 
>>>> 
>>>> ----
>>>> 
>>>> Karl Grossner
>>>> 
>>>> Technical Director,
>>>> World-Historical Gazetteer project for the
>>>> 
>>>> University of Pittsburgh World History Center
>>>> 
>>>> @kgeographer
>>>> 
>>>> Denver, CO
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> ----
>>> Ivan Herman, W3C
>>> Publishing@W3C Technical Lead
>>> Home: http://www.w3.org/People/Ivan/
><http://www.w3.org/People/Ivan/>
>>> mobile: +31-641044153
>>> ORCID ID: https://orcid.org/0000-0003-0782-2704
><https://orcid.org/0000-0003-0782-2704>
>>> 
>> 
>
>
>----
>Ivan Herman, W3C
>Publishing@W3C Technical Lead
>Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
>mobile: +31-641044153
>ORCID ID: https://orcid.org/0000-0003-0782-2704
><https://orcid.org/0000-0003-0782-2704>

Received on Saturday, 31 March 2018 15:01:14 UTC