W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > January 2015

Re: ISSUE-5 Definition of Resource

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Thu, 08 Jan 2015 15:06:01 -0800
Message-ID: <54AF0D59.3090009@gmail.com>
To: Arthur Ryman <ryman@ca.ibm.com>
CC: public-data-shapes-wg@w3.org
The three phrases that you nominate are defined in important W3C documents.  I 
agree that the working group should preferentially use them, even if working 
members believe that there is better terminology.

I believe that the working group is obligated not to use "resource" in the way 
that it is used in the Resource Shape spec.  I think that it would be a very 
good idea for the Resource Shape people to use a different word than resource 
for "RDF representation of an information resource".

I think that "RDF representation of an information resource" is not a phrase 
that even has a well-defined meaning.  It could mean the RDF graph that is 
returned under content negotiation when asking for an RDF syntax.  It could 
also mean the RDF graph that can be extracted from other representations of an 
information resource (e.g., PDF representations and HTML representations).  I 
think that these three graphs can be very different for particular information 
resources.

peter

On 01/08/2015 02:08 PM, Arthur Ryman wrote:
> Peter,
>
> We should agree on the following web terms:
> information resource
> real-world object
> representation of an information resource
>
> In the context of the Resource Shape spec, "Resource" = RDF representation
> of an information resource (not Dick Cheney)
> _________________________________________________________
> Arthur Ryman, PhD
> Distinguished Engineer | Master Inventor | Academy of Technology
> Chief Data Officer
> SWG | Rational
> 905.413.3077 (phone) | 416.939.5063 (cell)
> IBM InterConnect 2015
>
>
>
>
> From:   "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
> To:     Arthur Ryman/Toronto/IBM@IBMCA, public-data-shapes-wg@w3.org
> Date:   12/19/2014 02:33 PM
> Subject:        Re: ISSUE-5 Definition of Resource
>
>
>
> I went back through Cool URIs and httpRange-14 discussions, and some other
>
> stuff to check up on this.
>
> Which terms in the message are being proposed to be put up for working
> group
> consensus, by the way?
>
> On 12/18/2014 12:55 PM, Arthur Ryman wrote:
>> I'd like to summarize the discussion from the WG today and ask that we
>> arrive at a consensus on the meaning of terms. Here are definitions that
>> align with W3C specs.
>>
>>  From a web point of view, a resource is any identifiable thing. We
>> identify them using URIs.
>
> A resource is anything.  Not all resources are identifiable.  Not all
> identifiable resources are identifiable via URIs.  Not all resources that
> are
> identifiable via URIs are identifiable via HTTP URIs.
>
>>  From an HTTP point of view, there are two kinds of resource, namely
>> information resources and real-world objects. The term "real-world
> object"
>> denotes any resource that is not an information resource. This implies
>> that fictional characters are real-world objects.
>
> That's the terminology in Cool URIs for the Semantic Web
> http://www.w3.org/TR/cooluris/.  Older terminology talked about
> information
> resources and resources. Even though it seems strange to say that
> information
> resources are less real than fictional characters there appears to be no
> reason to not use the Cool URIs terminology.
>
>> An HTTP server should return a 3XX response code when a real-world
> object
>> URI that it hosts is requested via HTTP GET. The response should
> redirect
>> to an information resource URI that has information about the real-world
>> object.
>>
>> An HTTP server should return a 2XX response code when an information
>> resource URI that it hosts is requested via HTTP GET. The response
> should
>> contain a representation of the information resource in some content
> type,
>> ideally one of the content types given by the Accept header.
>
> In general, yes.  Various error conditions might produce different
> responses.
>
> Hash URIs are handled using a different method, but the URI access part
> works
> this way.
>
>> For the purposes of the wg, we are interested in RDF content types.
>
> For the RDF graph that is being validated, yes.
>
>> An RDF representation consists of a set of triples which can be thought
> of
>> as forming a graph, technically a directed, labelled graph.
>
> A set of RDF triples can be thought of as a kind of graph, but not exactly
>
> this kind of graph.  I'm not sure what "RDF representation" is supposed to
> be
> here, though.
>
>> The nodes in an RDF graph are labelled by RDF terms, i.e. URI, Literal,
>> and Blank Node. The arcs are labelled by URIs. There are other
> constraints
>> defined in the RDF specs.
>
> An RDF graph is a formal construct.  Nodes in an RDF graph are either
> IRIs,
> literals, or blank nodes.  RDF graphs don't have arcs or edges, instead
> they
> have triples whose subject is either an IRI or a blank node, whose
> predicate
> is an IRI, and whose object is either an IRI, a blank node, or a literal.
>
> When one thinks of an RDF graph as a regular kind of graph, one has to be
> very
> careful to be faithful to RDF graphs.  In particular, the graphs that
> correspond to RDF graphs are multi-graphs.
>
>> Since we can visualize graphs as geometric objects, the term "shape" has
>> been adopted to describe sets of graphs that share certain
>> characteristics, e.g. those required by some application. A shape
>> describes the expected contents of a graph. This includes expected arc
>> labels, occurrence constraints, etc.
>
> This bit was the subject of a previous email.
>
>> The term "resource shape" is an abbreviation for the "shape of the graph
>> of the RDF representation of an information resource".
>
> This last bit was the subject of a previous email.
>
> peter
>
>>
>> _________________________________________________________
>> Arthur Ryman
>> Chief Data Officer
>> SWG | Rational
>> 905.413.3077 (phone) | 416.939.5063 (cell)
>> IBM InterConnect 2015
>>
>>
>
>
>
Received on Thursday, 8 January 2015 23:06:33 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 8 January 2015 23:06:34 UTC