Re: Skolemization and RDF Semantics

On 21 April 2011 00:07, Pat Hayes <phayes@ihmc.us> wrote:
>
> On Apr 20, 2011, at 7:10 AM, Richard Cyganiak wrote:

>> On 17 Apr 2011, at 15:15, Pat Hayes wrote:
>>>> First of all, it is *sometimes* but not *always* bad to use blank nodes. The documents I linked to gave specific advice, informed by implementation experience, for when to use, and when to avoid, blank nodes.
>>>
>>> True, but it does say that the fewer bnodes the better, as a general rule about all data.

Yes, on balance, it's better to know information and to be able to
share it, than not.

But maybe bnodes even support business models under certain
circumstances? Publish public in LOD with a few annoying bnodes in
some parts of the graph, and sell 'platinum' access to a (cert for a)
richer URIs-everywhere graph.

[...]

> Of course. Nobody is suggesting *deliberately* using blank nodes when you could use a URI, just in order to make things difficult.  But there are many cases where it makes perfect sense to use a blank node simply because there is no natural  identifier available for the entity in question. For example, I am helping a company design a system to mark up art images using RDFa. I have a drawing of a reclining nude. How do I say this? I want to say the drawing depicts **a person** who is female, nude and in a reclining position. I have absolutely no idea who this person actually is, or even if there ever was a model for this drawing. It seems absolutely natural and correct for me to use a blank node here: the drawing depicts _:xx who has rdf:type :human and rdf:type :female and .. etc.. Obviously, I could coin a URI to denote this hypothetical model, but that URI would not convey anything that is not conveyed by the bnode, and it might well be interpreted to mean that I have information about the model (since I apparently have a name that 'identiifes' her, which URIs are said to do); but of course I don't have any information about her, which is why the bnode is useful.
>
> This kind of construction comes up in our project all the time; almost every artistic classification has a hidden existential in it somewhere (a landscape drawing is one that depicts **a** landscape, etc.. Are we to be obliged to invent URIs to refer to all these things? Every artwork will have a cloud of URIs surrounding it to refer to the people and places it might depict, the particular piece of paint that was used to make a particular mark, the particular composition line that it alone has, etc.. What purpose is served by this proliferation of unresolvable URIs?

The effect might be to discourage certain idioms...?

<Farmer> <sowed> <Corn> <kept> <Cock> <woke> <Priest> <married> <Man>
<kissed> <Maiden> <milked> <Cow> <tossed> <Dog> <worried> <Cat>
<killed> <Rat> <ate> <Malt> <in> <House> <builtBy> <Person
foaf:name=”Jack” /> </builtBy> </House> </in> </Malt> </ate> </Rat>
</killed> </Cat> </worried> </Dog> </tossed> </Cow> </milked>
</Maiden> </kissed> </Man> </married> </Priest> </woke> </Cock>
</kept> </Corn> </sowed> </Farmer>

(and don't get me started on URIs for events... :)

>> The early FOAF practice of using blank nodes for people is an interesting case study here. The idea was to use IFP inference plus rdfs:seeAlso links to form a web and join the blank nodes, but this didn't work very because this multi-step join process including IFP inference in practice is much more brittle than directly using someone else's resolvable URI.

Yes, that was a royal pain, but at the time there was no consensus
that it was legal to use handy HTTP URIs (or #'d ones, depending on
who you asked) for people, and there weren't other good candidates.
Per http://www.w3.org/DesignIssues/TermResource.html "So in response
to this, the HTTP protocol was, in fact, changed.".  IFPs are an
important technique for grounding otherwise unknown names against
better known ones - for figuring out in practical terms who some URI
refers to. But it helps when there is a target URI that you're trying
to ground, otherwise you can't really talk about what you're doing.

cheers,

Dan

Received on Thursday, 21 April 2011 10:28:32 UTC