Re: Pulling resources out of the graph (was Re: HTTP URIs for real world objects)

On 17/01/2008, Danny Ayers <danny.ayers@gmail.com> wrote:
> [cc's tweaked]

Adding in my PhD supervisors.

> On 17/01/2008, Peter Ansell <ansell.peter@gmail.com> wrote:
>
> > > The subject of this thread is about URIs for real world "objects". RDF's fatal flaw in this respect is that it makes no distinction between use and mention of a subject (think Alice Through the Looking Glass and "the name of the song" - Lewis Carroll knew what he has talking about). I would still maintain that PSIds answer that requirement unequivocally, however poorly it might be considered that the documentation supports that view.
> >
> > I think any assertions with the ID/URI as the subject of a statement
> > should be regarded as defining a property specifically about the thing
> > that is being referred to.
>
> Yes...I'm not sure I follow the use/mention point as it relates to RDF.
>
> This could simply be my early-morning confusion. I was about to
> suggest this issue does arise with RDF when used over HTTP for
> documents (information resources), as when you do a GET on a Web
> resource you always get a representation of that resource, not a
> description of that resource (the issue discussed by Patrick Stickler
> around URIQA [1]).

If you have separate documents to describe and represent the resource
than you may have a problem. However, you will always know whether you
are searching for a Resource or a Literal using the initial triple.

If there is a literal that points to a http address than it is safe to
say you won't be going to it to get any descriptions about a resource
identified by that address. I would prefer to completely separate
resource descriptions from resource representations and enforce an
arbitrary standard that Resource identifiers used on other semantic
documents always point to the resource description, which then
includes a triple which could direct them to the representation if
they felt they needed to retrieve that. The representation triple
should always specify the representation page as a literal xsd:uri
typed string so as not to confuse people about its use.

RDF is meant for computers remember, not humans, so having an ontology
instruction embedded in an RDF document to direct a user-agent to a
human-readable description seems like the way to keep with the simple
RDF/OWL mix and still allow for both humans (with appropriate
user-agents) and computers.

The advent of people mixing RDF statements into otherwise normal HTML
pages with RDFa and other related languages may just be a side issue
here as long as people can still figure out whether the strings they
are putting in are semantic URI's or literal strings.

> But I can't actually see the problem there right now... Seems to me a
> description of something is a legitimate form of representation of it
> - so if the publisher deems it appropriate, they can use the URI of
> the resource as the subject of statements within the RDF
> representation. i.e. no distinction is needed. Alternately, the
> httpRange-14 trick of returning a 303 redirect could be used to
> provide a description.

I am not convinced about the value of this, as it does not provide an
RDF triple based solution, where an ontology would provide it. I still
see it as safe to say that when computers traverse RDF graphs, they
don't want to be disambiguating things based on the transport or other
layers, when they are performing all of their other queries at the RDF
document/triple layer.

> Incidentally, something I assume is closely related to the use/mention
> point (whatever that may be :-) is something that's been bugging me
> for a while. Say a HTTP GET on <uri> returns a doc containing the
> statement:
>
> <person> foaf:homepage <http://example.org/home> .

In this case http://example.org/home may be better left as a literal,
unless it is an entity which may provide more semantic information
that an RDF Resource implies

<person> foaf:homepage "http://example.org/home"^^xsd:anyUri .

> What can we say of the relationship between the resource <uri> and the
> resources <person>, foaf:homepage and <http://example.org/home>?
>
> Resources in RDF graphs are always linked nodes, but when HTTP is
> brought into the picture it's as if there's an air gap between the
> graph and the resources it involves. Can they somehow be reified?
> (Generally, not as in RDF reification). Given the GET, would it be
> reasonable to infer statements something like:

Literals may help here.

> <uri> :involves <person> .
> <uri> :involves foaf:homepage .
> <uri> :involves <http://example.org/home> .

As above I am not sure that the third one needs to contain an RDF
Resource as its Object. Literal would work fine for me as it doesn't
imply you can do anything more with the string other than go to it to
find a homepage for the given person.

> where :involves would probably be a subclass of rdfs:seeAlso
> ("involves" is an awful term but I'm not sure whether this is "uses"
> or "mentions" :-)

I would love to have a term to use which said more than seeAlso but
didn't go as far as saying definedBy or sameAs, as they don't
necessarily say the right things. It has to basically say this
information is specifically related to the given term, as opposed to
seeAlso which says, if you want to you can find some related
information. definedBy

> This could be useful from a linked data perspective, in providing a
> follow-your-nose path from e.g. <person> to <uri> (as links work both
> ways) which might not otherwise exist even though <uri> provides
> information about <person>.

Links should other work both ways if you put both in a document as
Resources. If however you put one in as a string then you avoid any
duplicity.

> But does it break anything?

It seems like a simple extension, and if you didn't understand the
ontology you would not be affected by it.

> (I was hoping the named graph docs might help here, but the HP links
> from http://www.w3.org/2004/03/trix/ are 404ing)
>
> Cheers,
> Danny.
>
> --
>
> http://dannyayers.com
>

Received on Friday, 18 January 2008 01:33:02 UTC