Maybe you can tell us more about your use case(s) and the workflow(s) with 
which you expect to use this data?

There is no general best practice here, but there are techniques that are 
better and worse for some given situation.

ajs6f

> On May 23, 2018, at 10:31 AM, Laura Morales <[email protected]> wrote:
> 
> I could do that, but can it be considered good practice? Other approaches are
> 
> - make my own URI scheme, for example <mydocs:name/doc1>
> - make my own URN NID like <urn:mydocs:doc1> but NIDs are supposed to be 
> registered
> - the info: scheme has been deprecated, so I should not use <info:mydocs/doc1>
> 
> I don't think RDF is providing any "best practices" suggestions or guidelines 
> for a scenario like this, and it's pretty frustrating because not all data 
> need to be dereferenceable and not all data need to have a universally unique 
> ID such as ISBN or telephone number...
> 
> 
> 
> 
>  
>  
> 
> Sent: Wednesday, May 23, 2018 at 3:26 PM
> From: ajs6f <[email protected]>
> To: [email protected]
> Subject: Re: Nodes without dereferenceable URIs
> Can you use HTTP URIs that simply don't point to an actual server? (E.g. 
> http://lauras.namespace/blah/blah/blah)
> 
> If no one tries to dereference them, it's fine if they don't work. If someone 
> might try to dereference them, that's when you might have problems.
> 
> ajs6f
> 
>> On May 22, 2018, at 2:01 PM, Olivier Rossel <[email protected]> wrote:
>> 
>> Don't use blank nodes. You will regret it in the long run.
>> 
>> On Tue, May 22, 2018 at 4:43 PM, Laura Morales <[email protected]> wrote:
>> 
>>> How can I deal with a RDF graph where I don't have dereferenceable URIs,
>>> but still need the URIs to link with other graphs? For example if I have a
>>> personal graph of documents that I only need to use for myself, what URIs
>>> should I use?
>>> 
>>> Blank nodes?
>>> 
>>> _:document1
>>> _:document2
>>> _:document3
>>> 
>>> or do I make my own URNs?
>>> 
>>> <urn:mybooks:title:document1>
>>> <urn:mybooks:title:document2>
>>> <urn:mybooks:title:document3>
>>> 
>>> what other solutions are available?
>>> 
>  

Reply via email to