W3C home > Mailing lists > Public > public-lod@w3.org > March 2020

Re: blank predicates

From: Hugh Glaser <hugh@glasers.org>
Date: Sat, 28 Mar 2020 12:30:33 +0000
Cc: Linked Data community <public-lod@w3.org>
Message-Id: <709A2AF9-D785-4D22-988B-B1C5027C9D07@glasers.org>
To: Melvin Carvalho <melvincarvalho@gmail.com>
Hi Melvin,
I hope you (and all on the list are well and keeping safe as possible).

Pretty much wot Dan said.
I don't see the problem, really.

What's the knowledge you have?
Alice has a connection to Bob?
So that's what you say
#Alice ns:connection #Bob .

Because that's all you can say.
And if that knowledge isn't useful, leave the triple out.
=========================================
But there may be more to it?
Do you want to know if there is more than one connection.
Or you may be you want to elaborate on that connection later?
In which case you could create a different predicate for every relationship - probably with a random string rather than something that encoded Alice & Bob in it, but that would be bad for multiple connections.
I hope the store you are using is happy with lots of predicates, if you do.

I find myself wondering whether you are being misled that because your data is a graph, the RDF graph should have a similar topology?
Is it not the case that it is the connections that you have knowledge about?
And possibly want to make statements about.
So you create multiple triples for this knowledge of s single edge in your map.
And I even think you could then use blank nodes for the connections, if you wanted.
I know this would sort of look a bit like reification, but it isn't - it would be an RDF graph representing the knowledge you want.

Finally, I also find myself wondering whether property graphs won't work better for you, but wouldn't dare say that on this list ;-)
Although I note you say:
> My software currently does not allow the labeling of edges is the reason (but hopefully in future it will)
which sounds like you are going down that road.

Best
Hugh

> On 28 Mar 2020, at 12:07, Dan Brickley <danbri@danbri.org> wrote:
> 
> 
> yup - really just invent a property for it
> 
> or say nothing by not adding a triple
> 
> unless you have some kind of idea how the things are sort-of related then the triple adds literally no information 
> 
> 
> 
> On Sat, 28 Mar 2020 at 10:19, Claus Stadler <cstadler@informatik.uni-leipzig.de> wrote:
> <> is a relative IRI with an empty string relative to some base IRI - so Linked Data clients will typically replace it with the file:// or http(s):// URL of the document they read from.
> 
> So don't use that, unless you want location-dependent predicates :)
> 
> 
> 
> Cheers,
> 
> Claus
> 
> 
> On 28.03.20 11:03, Melvin Carvalho wrote:
>> 
>> 
>> On Sat, 28 Mar 2020 at 10:53, Dan Brickley <danbri@danbri.org> wrote:
>> 
>> there are an infinite number of boring relationships that hold between any arbitrary pair of objects; your best bet might be to name one for your application rather than attempt to use generalized (predicateless) rdf
>> 
>> So maybe simply <> ?
>> 
>> #Alice <> #Bob .
>>  
>> 
>> Dan
>> 
>> On Sat, 28 Mar 2020 at 08:57, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
>> I am working on a information mapping system (aka mind maps)
>> 
>> And I want to have two nodes related to each other
>> 
>> #Alice R #Bob
>> 
>> In the general sense, the type of relationship (predicate) R is not really known at the time of creation.  My software currently does not allow the labeling of edges is the reason (but hopefully in future it will)
>> 
>> I need a way to relate Alice to Bob but I dont have a URI for a predicate.
>> 
>> Is there something that can operate as a "blank predicate"?  
>> 
>> Or some existing relations that simply says that two entities or linked / related, without yet knowing how they are related?
> -- 
> Dipl. Inf. Claus Stadler
> Department of Computer Science, University of Leipzig
> Research Group: 
> http://aksw.org/
> 
> Workpage & WebID: 
> http://aksw.org/ClausStadler
> 
> Phone: +49 341 97-32260
> 

-- 
Hugh
023 8061 5652
Received on Saturday, 28 March 2020 12:30:53 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 28 March 2020 12:30:54 UTC