commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Seaborne <a...@apache.org>
Subject Re: [RDF] Local Scope and BlankNode internalIdentifier (was: github Commons RDF vs. Apache Commons Sandbox RDF)
Date Mon, 02 Feb 2015 22:01:21 GMT
Hi Reto,

There is a key point in this disussion that is worth pulling out.

RDF has a data model and there is also an interpretation of the data model.

The data model is one spec ("Concepts and Abstract Syntax") and the 
interpretation in another ("Semantics", also commonly referred to as the 
Model Theory).  There others semantics as well (RDFS, OWL-x etc).

The Model Theory only reflects unchanging graphs.  "Lean graphs" are in 
the model theory.

RDF data has to be built in the first place using the Data Model.

This layering should be reflected in code.

The commons rdf API should reflect the Data Model; how to build graphs 
how they can be manipulated.  Systems can then be built on top of that - 
including Clerezza leaning graphs, or owl:sameAs prototype chains (which 
interact with leaning) or RDFS inference or ...

Does that work for you?

	Andy

On 31/01/15 20:45, Reto Gmür wrote:
> Hi Andy,
>
>
> This analogy might help (or not):
>>
>> There is a table with 4 metal spheres on it in a line across it.  Each
>> sphere is exactly kind of material, the same mass, the same colour and the
>> same shininess.  You can ask "is that sphere the same as that other one?"
>> by pointing to two of them.  If you put them in a bag, shake the bag and
>> take one out, you can't tell whether this chosen one is the same as the one
>> that was on the right-hand end of the line.
>>
>
> How many Spheres will you be able to take out of the bag? I once made the
> mistake (resulting in a bug) to assume identity of the indiscernible in
> RDF, this is however not the case.
>
> To have the sphere exist they need to be part of graph.
>
>
> If this is the graph:
>
> _:a p _:b.
> _:b p _:c.
> _:c p _:d.
> _:d p _:e.
> _:e p _:a.
>
> We can put the 5 sphere to the bag and shake as much as we want we will
> always have 5 spheres in the bag. Of course, as you say, if we take one out
> we can say which one it is. (But we don't care, we are happy having a shiny
> meta sphere in a circle  with 4 other spheres).
>
> By contrast if this is the graph:
>
> _:a rdf:type ex:Sphere.
> _:b rdf:type ex:Sphere.
> _:c rdf:type ex:Sphere.
> _:d rdf:type ex:Sphere.
> _:e rdf:type ex:Sphere.
>
> When we open the bag we might just have one sphere. Which is fine, as the
> above graph evaluates to true in any world where there is at least one
> sphere.
>
>
> So far for what RDF is concerned. Things are a bit different for the API
> that allows creating the graph, in this situation we might actually be
> pointing (or looking) at spheres and as long as we do so they should not
> disappear. After having added the above 5 triples we might go on adding:
>
>
> _:a rdf:type ex:Shiny.
> _:b rdf:type ex:Heavy.
> _:c rdf:type ex:Radiactive.
> _:d rdf:type ex:Transparent.
> _:e rdf:type ex:Whole.
>
> In this case we should have 5 spheres described by 10 triples. Every well
> behaving quality bag will give as back all 5 spheres[*].
>
> In other words as long as I am looking at the spheres I might go on adding
> things to theirs descriptions making them actually distinct spheres.
>
> This distinction between being looking at (or pointing at) spheres and just
> having them in the bag is very straight forwardly (and imho elegantly)
> modeled with the distinction of an object instance being reachable or not.
>
> In the clerezza code and in the SVN commons proposal code along the
> following lines will works as expected.
>
> {a,b,c,d,e} is a set of 5 BlankNodes (i.e. we have 5 objects, no two of
> them are equals).
>
> g.add(a, RDF.type, EX.Sphere);
> g.add(b, RDF.type, EX.Sphere);
> g.add(c, RDF.type, EX.Sphere);
> g.add(d, RDF.type, EX.Sphere);
> g.add(e, RDF.type, EX.Sphere);
> //if we save the graph here the backend might just store one triple
> //but as long as wen can do the following
> g.add(a, RDF.type, EX.Shiny);
> g.add(b, RDF.type, EX.Heavy);
> g.add(c, RDF.type, EX.Radiactive);
> g.add(d, RDF.type, EX.Transparent);
> g.add(e, RDF.type, EX.Whole);
> //we will end up storing 10 triples
>
> In the API proposal it is neither clear in which situations the backend
> might remove redundant information (as new blanknodes object with the same
> id might be created with the same factory) nor if the latter 5 add
> invocations will indeed add triples with the same subject (as the
> implementation might have created bnodes that differ from the original 5 as
> these might originate from another graph, see my answer to Stian).
>
> So basically I agree with everything you write in your email and don't see
> any reason to expose the internal identifier in the API and have complex
> identity criteria.
>
> Cheers,
> Reto
>
>   [*] Well, yeah the problem of the metaphors: we will always get back 5
> bnodes, even though the graph also evaluates to true in a universe with
> just one shiny, heavy, radiactive, transparent and whole sphere.
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message