Re: the state of ldp-patch, and a procedural proposal

On 10/3/13 5:03 PM, Wilde, Erik wrote:
> hello kingsley.
>
> On 2013-10-03 13:29 , "Kingsley Idehen" <kidehen@openlinksw.com> wrote:
>> A URI denotes.
>> An HTTP URI denotes and locates.
> maybe. if it is deferencable, then it locates, otherwise it doesn't.

What makes it dereferencable?

It's the protocol denoted by the scheme that implies data (resource) 
access. That's why you have "Locator" in URL since an HTTP URI has 
duality (Naming and Addressing).

With regards to Linked Data, the basic principles boil down to HTTP URIs 
being dereferencable while also exploiting the Name / Address duality 
(or as some might say: ambiguity).

> some/most HTTP URIs are dereferencable, some are not, and that's perfectly
> fine, too.

In the context of RDF based Linked Data, not being able to lookup of the 
description of what an HTTP URI denotes is more of a reflection of data 
(resource) state i.e., time variant nature of Web resources.

>   simply put, URIs are just identifiers, URIs by themselves are
> never "links".

In the context of RDF based Linked Data, they are Names that resolve to 
Data (RDF statements) at a Location on a Network.

> depending on where they are used, they may *also* be
> actionable links. but you cannot tell by looking at them. you can only
> tell by their context.

And as I've stated repeatedly, "in the context of RDF based Linked Data" 
they behave as I've described. That's is the baseline spec for RDF based 
Linked Data i.e., the fundamental principles etc..

>
>> If the interpretation in question has nothing to do with RDF based
>> Linked Data, it still doesn't change the fundamental fact that URIs
>> (irrespective of scheme) denote entities (things).

Correct !!

> not sure why you seem to really dislike calling the identified
> entity/thing a "resource", thereby using the terminology of the URI
> standard itself.

Because "resource" is the problem. It will soon be yanked out of all 
literature for which it serves to simple confuse rather than enlighten. 
I believe that effort is actually in progress.

> but yes, URIs identify resources/entities/things, and
> when used in a context where they are used as links, they better be
> dereferencable or you have a problem.

Sorta, since "resource time variance" is also part of AWWW.

>
>>> personally, i never really liked that part of web architecture very much,
>>> because it means that if you do things such as content negotiation, it
>>> is
>>> your responsibility to make sure that fragment identifiers work
>>> consistently across supported media types.
>> I read it differently, and I find it a great showcase for architectural
>> dexterity .
>>> which is doable, but just feels
>>> a bit strange. i think there's a lot of history to why this is how it
>>> is,
>>> and starting from scratch this part of web architecture could be
>>> designed
>>> a little bit better now, but that's mostly an interesting thought
>>> experiment. the main point to keep in mind is: fragment identifier
>>> semantics are not defined by URIs or URI schemes, they are defined by
>>> media types.
>> Nothing to do with media types, nothing at all. URIs are the denotation
>> mechanism that sit at the core of AWWW.
> RFC 3986: "The semantics of a fragment identifier are defined by the set
> of representations that might result from a retrieval action on the
> primary resource.  The fragment's format and resolution is therefore
> dependent on the media type of a potentially retrieved representation,
> even though such a retrieval is only performed if the URI is dereferenced.
>   If no such representation exists, then the semantics of the fragment are
> considered unknown and are effectively unconstrained."
>
> - if you use URIs as identifiers, fragment identifier semantics are
> unknown/unconstrained.

Not in the context of RDF based Linked Data.
>
> - if you use URIs as links, fragment identifier semantics depend on the
> media type(s).

I use then to denote entities in the context of RDF based Linked Data.


Kingsley
>
> cheers,
>
> dret.
>
>
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen