- From: Ivan Herman <ivan@w3.org>
- Date: Mon, 2 Apr 2018 18:08:43 +0200
- To: Sandro Hawke <sandro@hawke.org>
- Cc: Sandro Hawke <sandro@w3.org>, Dan Brickley <danbri@danbri.org>, karlg <karl.geog@gmail.com>, Gregg Kellogg <gregg@greggkellogg.net>, Linked JSON <public-linked-json@w3.org>
- Message-Id: <6322128F-697A-4B08-9B0F-0B9E3CC118AC@w3.org>
Sandro
(sorry for the late reply, I was on the road…)
you are probably right that, semantically, it is (practically) the same. At least I do not see an flaws in what you say. One could wonder about how these attributes are related to and RDF semantics, actually. (If a triple is entails another triple via, eg, subProperty, should the attributes be assigned to the entailed triple? The property graph model does not deal with entailment, ie, this question is not relevant._
However, I think that the fact that this is considered to be a special case of a much more general concept is something that may be difficult for many to understand. It also means a difficulty in implementations: implementing graphs in a triple store is a different, and probably much more complex thing to do than to implement the fact of assigning attributes to an edge in the graph. The advantage of the property graph model is that it gives a simple syntax to a (in this sense) much simpler concept…
One could also wonder about how these attributes are related to and RDF semantics, actually. (If a triple is entails another triple via, eg, subProperty, should the attributes be assigned to the entailed triple? The property graph model does not deal with entailment, ie, this question is not relevant…)
But I guess we are diverging a lot! The fundamental fact that this should not be on the shoulders of the JSON-LD designers remains true I believe.
Cheers
Ivan
> On 31 Mar 2018, at 17:00, Sandro Hawke <sandro@hawke.org <mailto:sandro@hawke.org>> wrote:
>
>
>
> On March 31, 2018 2:59:15 AM EDT, Ivan Herman <ivan@w3.org <mailto: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>
>> <mailto: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>
>> <mailto:danbri@danbri.org <mailto:danbri@danbri.org>>> wrote:
>>>>>
>>>>> At Schema.org <http://schema.org/> <http://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>
>> <mailto:karl.geog@gmail.com <mailto:karl.geog@gmail.com>>> wrote:
>>>>> Sub-classing schema.org <http://schema.org/> <http://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>
>> <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>
>> <mailto: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>
>> <mailto: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>
>> <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>
----
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 Monday, 2 April 2018 16:08:54 UTC