Re: Indicating Skolem Nodes (was Re: AW: {Disarmed} Re: blank nodes (once again))

A weird thing that seems to be emerging from the discussion, is that there turns out to be
a use of URNs in the end: perhaps as skolem constants.

BNodes are useful because they allow publishers to

1. talk of things that they cannot name, and perhaps have no way of singly identifying - as when trying to speak of the two identitical balls swirling around in Gareth Evans' example in "The Varieties of Reference"
2. Not have to name things for which they don't want the longer term responsibility (URLs are interefaces for long term communication

But BNodes are perhaps too short lived. What may be useful would be slightly longer lived identifiers, that can be used in a conversation.

So I would add a suggestion to the URI schemes below something like the tag scheme, but with a time limit{deathTimeStamp}:{uniqueId}

This would allow one to create bnodes with limited life expectancy, that would still be globally valid.

It would be different from tag: uris, as those are trying to do the opposite: create identifiers that are tied to a domain, last for until after the life of the domain.

The reason for being against linked data in bnodes, is that those create reasons for people to link to things, which one wants to avoid in a bnode situation.


On 25 Mar 2011, at 17:57, Sandro Hawke wrote:

>> In triplestores I'm familiar (admittedly not that many) with bNodes are skolemised into a value space that's different from both literals and URIs, so this is a natural consequence.
> So, is there a simple way we can flag them?   I know it's out of scope
> for the RDF WG to define one, but maybe there's a solution that's so
> simple everyone can just start doing it without a W3C process.
>        Strawman 1: make new URI scheme for this
> Con: very hard to do. (It took me and Tim Kingberg 4+ years to get the
> "tag:" URI scheme RFC published.  Hopefully it's gotten much easier, but
> still I'm hesitant.)
> Con: it wouldn't be a link for linked data
>        Strawman 2: use urn:uuid:<uuid>
> Con: there might be some false-positives, because of people using UUIDs
> who don't mean them like this
> Con: might be longer than necessary
> Con: no helpful human-readable element
> Con: no link for linked data
>        Strawman 3: use,2000:Skolem:<some optional
>        text>:<uuid>
> Con: no link for linked data
> Con: might be longer than necessary
>        Strawman 4: use any IRI with some magic string in it, like
>        "SkBNode" or "$+SKNB+$".
> Con: some false positives, as magic string may appear in a few IRIs
> where it was not intended (such as blog posts about the concept, which
> use it in the title, or other naive machine generated URLs).
> For me, the clear winner is Strawman 4, because I really like being able
> to dereference stuff, even if it's a Skolem constant.  This allows the
> Skolemizer to provide web service if it wants to.  You can also use 4
> with a tag: URI if you don't want to support dereference.
>    -- Sandro

Social Web Architect

Received on Wednesday, 30 March 2011 13:35:00 UTC