Proper namespaces
Linde, A.E.
T.
--
Tony Linde
Project Manager
Department of Physics & Astronomy
University of Leicester
Norman Gray
Tony, hello.
A bit of thinking aloud here...
On 2009 Feb 19, at 12:19, Linde, A.E. wrote:
> The attached file contains an annotation added to a SAC by
> Spacebook. Given what we've found out about myExperiment now (esp at http://rdf.myexperiment.org/ontologies/
> ), should I be changing some of my namespacing? I'm not sure of the
> rules and accepted practices. Any suggestions?
No, the namespaces you're using in that annotation are fine. Thinking
about it, the only place where it might be worth an adjustment is:
<> a skua:annotation;
That <> is resolved relative to the base URI which is the annotation's
URL.
If I retrieve <http://apps.myskua.org/qsac-latest/sac/tonylinde> I get
a number of locally-minted URIs, including <http://apps.myskua.org/qsac-latest/sac/tonylinde/claim/2
>, <http://localhost:3000/workflows/3> and <http://localhost:3000/users/1
>. The first one's fine, but the others less so, on a publicly
available service, because they can't be retrieved.
Now, as you say, that's happening because those identifiers are minted
by an instance of Spacebook running on localhost. What else can it do?
...actually, there's very little else it can do. Ultimately, I
suppose, Spacebook would live on a public site (with an outward-facing
server, that is, not that its contents would be public), so that the
identities minted by it, including its domain name, would be perfectly
reasonable. Even on an intranet-only or single-host installation.
Thus I suppose the conclusion here has to be that one should generally
not save claims which originate in an intranet-only or single-host
installation of Spacebook on a SAC which lives in a different network
context, because in the context of that networked SAC, localhost means
multiple things. It's not that anything will immediately break, just
that it smells bad, and something will go wrong somewhere.
So, after all that, I don't think there's anything you need do! When
all this is deployed, the Spacebook and the SAC will generally be
sitting at the same 'level' of host/intranet/internet, so there won't
be a problem.
See you,
Norman
--
Norman Gray : http://nxg.me.uk
Dept Physics and Astronomy, University of Leicester
Linde, A.E.
I’m hoping to be able to construct a SAC identifier for each Spacebook user based on the id they get from myExperiment when they sign up: that will obviate the need to store their SAC endpoint which I’d have trouble doing at the moment because of the way ruby/rails works. It will mean that if someone wanted their Spacebook annotations stored in some other SAC, they’ll have to change the endpoint every time they annotate but since they can federate to the Spacebook SACs they shouldn’t need to do that.
Once I’ve got that working, we could actually deploy a working version of Spacebook for others to try out.
T.
Norman Gray
Tony, hello.
On 2009 Feb 19, at 13:18, Linde, A.E. wrote:
> I'm hoping to be able to construct a SAC identifier for each
> Spacebook user based on the id they get from myExperiment when they
> sign up: that will obviate the need to store their SAC endpoint
> which I'd have trouble doing at the moment because of the way ruby/
> rails works. It will mean that if someone wanted their Spacebook
> annotations stored in some other SAC, they'll have to change the
> endpoint every time they annotate but since they can federate to the
> Spacebook SACs they shouldn't need to do that.
Ach, yes -- that's the best way. There's some debate in the LOD world
of whether it's best to mint URLs promiscuously or try as hard as
possible to reuse them. In this case I think it's clear -- reuse the
URL which myExperiment creates.
I think that http://rdf.myexperiment.org/Users/nnn would be an
excellent URL for a user. Its uniqueness is guaranteed by the
myexperiment.org registration, it's dereferenceable to give RDF. Ideal!
Linde, A.E.
I have actually asked whether to use http://www.myexperiment.org/Users/nnn or http://www.myexperiment.org/users.xml?id=nnn, which are the website and api equivalents.
In fact, what I was really talking about below, re ‘SAC identifier’, was the identifier of the SAC itself, so using http://apps.myskua.org/qsac-latest/sac/SBnnn or similar for the SAC endpoint.
T.
Norman Gray
Tony,
On 2009 Feb 19, at 15:04, Linde, A.E. wrote:
> Actually, I hadn't considered using http://rdf.myexperiment.org/Users/nnn
> : that is because the RDF does not sound like it is fully supported.
> It is generated by converting the whole database to RDF each night
> so the RDF only reflects the last (might's) snapshot of the
> database. I can see this being abandoned if the db gets too large.
> Anyway - we'd have to then replicate this nightly generation for any
> and all Spacebook deployments - not a good idea.
Mmm, I see what you mean. However, supposing that the same .../Users/
nnn were generated each night for a given user (presumably the case,
if it reflects <http://www.myexperiment.org/Users/nnn>, then it would
probably be _stable_ enough for our purposes.
However if they might abanodon it, then that doesn't really work. Do
they know about D2RQ and SquirrelRDF (I presume they do, since De
Roure is a semantics person)? The idea there is that D2RQ acts as an
interface to your RDBMS: it accepts SPARQL queries, turns them into a
SQL query on the live RDB, and transforms the result back to RDF. It
also means you can dereference the IDs it creates to give RDF from the
RDBMS. I've set it up in a simple case, once, over an afternoon.
> In fact, what I was really talking about below, re 'SAC identifier',
> was the identifier of the SAC itself, so using http://apps.myskua.org/qsac-latest/sac/SBnnn
> or similar for the SAC endpoint.
Do you mean giving a user an identity such as http://apps.myskua.org/qsac-latest/sac/SBnnn/user/99
if they're user 99 on myExperiment? That's a sort of duplication
that sounds pretty fragile to me.
Linde, A.E.
And, no, the user identity is something different. I was talking about the actual SAC endpoint. So if user 99 is created by Spacebook, they will have a SAC created for them with the endpoint http://apps.myskua.org/qsac-latest/sac/SB99 and this will be the default to which any annotation is made.
The actual identity for user 99 will be one of:
http://astrovre.org/users/99
http:// astrovre.org/user.xml?id=99
http://rdf. astrovre.org/Users/99
if we assume that we’re talking about a deployment of spacebook at astrovre.org.
T.