Re: Linked Data on qdos.com

Steve,

Thanks for the interesting background! I'm delighted to learn that  
qdos does RDF not just on the outside, but also in the backend!

On 3 Dec 2007, at 11:03, Steve Harris wrote:
>> At the moment, unfortunately, the URI scheme is broken. It uses the  
>> same URI to identify two different things, a web document and a  
>> person. Web documents are different things than the things talked  
>> about in the document -- that's a fundamental axiom.
>
> Well, not exactly - the URI originally denoted the person, and the  
> HTML profile page was http://qdos.com/profile?uri=... which was  
> ugly, and the persons URI did not dereference to anything. So, I  
> made the person's URI dereference to .../turtle if you Accept:'d  
> application/x-turtle

Okay, fine until here ...

> and return some HTML if not.

That's the crux -- Returning any content, be it HTML or RDF, makes a  
URI identify a web document. And it cannot possibly identify a person  
at the same time. That's the collision.

There are only two ways around this:

1. Using a hash URI for the person, but as you explain below, this  
isn't an option in our case.

2. Using different URIs for person and document, and 303(!)- 
redirecting from the person URI to the web page URI.

> Consequently there's no statements about the page with <http://qdos.com/celeb/8340a9fc46297f805e66b6f9e89feb80 
> > as the subject.
>
> Probably/possibly I should have made the html version .../html or  
> something, but I didn't. I might change this in the future, but I  
> want to avoid forwarding normal users all over the place.

Yes, I agree -- redirecting normal users is not good.

How about putting the HTML pages at <http://qdos.com/profile/ 
83...eb80> or something? This would be different from /celeb/, and  
still be a nice and clean URI. Always use that URI when linking from/ 
to HTML pages -- no need to redirect.

Then you would have:

<http://qdos.com/celeb/83...eb80>
the celebrity, a person -- 303-redirects to:

<http://qdos.com/celeb/83...eb80/turtle>
an RDF web document about that person

<http://qdos.com/profile/83...eb80>
the profile page, an HTML web document about a person; the only URI  
that normal users will ever see.

If you want to get really fancy, then make the 303-redirect go to the  
third URI if the client did not specifically ask for RDF.

(...)
>> DC date and creator refer to the SPARQL graph, not the HTML page.  
>> The HTML is dynamically generated.

Well, the date and creator certainly do not refer to the person, and  
you shouldn't publish them attached to the person's URI.

>> Fortunately, fixing this is fairly easy:
>>
>> 1. Make up your mind which properties are properties of the person,  
>> and which are properties of the QDos web page. I'd argue that  
>> almost all are about the person.
>>
>> 2. Use http://qdos.com/celeb/834...3b80#person as the URI for all  
>> the things where you mean the person.
>
> You cannot be serious! There's no way I would go through and change  
> every URI referring to a person in the RDF store behind a live system.

Sorry -- I didn't know that the URIs come from an RDF store. I naively  
assumed there was a database in the back, and the triples were  
generated by a template.

Then the URIs for the people have to stay as they are. I hope that the  
HTML page URIs can still be changed, as I suggest above.

>> 3. Add a triple that relates the document and the person, e.g. <... 
>> 3b80> foaf:primaryTopic <...3b80#person>.
>>
>> Optionally, I'd suggest a few additional things:
>>
>> 4. A triple <...3b80#person> rdf:type foaf:Person would be helpful.
>
> Users get a rdf:type foaf:Person triples, celebs get rdf:type  
> q:Celebrity, which should be a subClassOf foaf:Person, but I've not  
> got round to adding that to the schema.

+1 -- I've seen the classes in the schema, would be great to have them  
used in the data.

> The URI of the graph is the same as the URI of the person. That's  
> slightly odd, but we have a lot of queries like
>
>   GRAPH ?person {
>     ?person ?prop ?obj .
>     ...
>   }
>
> That are used to stop queries spanning graphs. SPARQL doesn't have a  
> concatenate function we could use to do
>
>   GRAPH concat(?person, "/graph") { ?person ... }
>
> or whatever.

I see -- makes sense to me. The only problem is when you mix metadata  
about the graph with data about the person in the public RDF.

>> 5. The HTML page could include an autodiscovery link to the RDF in  
>> the <head>:
>>
>>  <link rel="alternate" type="application/x-turtle" href="...3b80/ 
>> turtle" />
>
> That was on the todo list, thanks for pointing out the appropriate  
> rel. I thought I'd seen rel="semantics" somewhere. I've just added a  
> link of that form.

Great, thanks for this.

(The typical choices are rel="meta" and rel="alternate". The former is  
appropriate for pure RDF metadata about the HTML page (who made it,  
when, what's its topic ...), while the second one is appropriate for  
an RDF version of the content of the HTML page. I figure that our case  
is closer to the second.)

>> 6. Yes, RDF/XML output would be *very* helpful and is pretty much  
>> needed to be compatible with the rest of the Linking Open Data  
>> project. RDF/XML can be serialized in a simple line-by-line way,  
>> just like N-Triples (only much uglier).
>
> Sure, it requires a newer version of the RDF store, which will have  
> to wait for a scheduled maintenance period.

Looking forward to this upgrade!

> The turtle is just the output of a CONSTRUCT query.

Ah, interesting. I like this.

Best,
Richard



>> I realize that it's not always easy to justify spending time on the  
>> subtleties of semwebby things, but I think it's important to get  
>> this right.
>
> Right, within reason I'm happy to make changes that will make our  
> corner of the semweb world a nicer place to be.
>
> - Steve
>

Received on Monday, 3 December 2007 18:18:32 UTC