W3C home > Mailing lists > Public > public-vocabs@w3.org > September 2012

Meaning of property "url"

From: Cord Wiljes <cwiljes@cit-ec.uni-bielefeld.de>
Date: Mon, 10 Sep 2012 13:27:10 +0200
Message-ID: <504DCE8E.3090803@cit-ec.uni-bielefeld.de>
To: public-vocabs@w3.org
Hi Michael,

> (schema.org's "url" property) means something very specific:
> "this is the Web location of" _____ (where ______ is some network
> addressable digital file).

That is what I thought, too. But the I wonder why:

  * "url" is a property of class "Thing" (instead of just class
    "CreativeWork")
  * there is no property "homepage" for class "Person" or "website" for
    class "Organization"

Cord


Am 10.09.2012 12:31, schrieb Michael Hopwood:
> Cord,
>
> This is the URI / URL / URN discussion again.
>
>>>> Or in other words: "url" means something rather general: "There is a web document related to the resource that can be retrieved at this url."
> The opposite, it means something very specific: "this is the Web location of" _____ (where ______ is some network addressable digital file).
>
> A URI is just a Web syntax used to identify stuff because the HTTP syntax conveniently allows you
>
> a) control over the lookup so you can put some description there (as you said);
>
> b) uniqueness also because of a) and the way the HTTP is set up.
>
> HTTP URI is paradoxically a very general protocol with very limited application ;)
>
> What is lacking is the infrastructure to ensure persistence, quality of lookup and a lot of other things. Most URNs in practical application have those but without the nice HTTP aspect, but in principle they can get it as an added service (e.g. ISBN-A).
>
> DOI is an attempt to add all those features together an generalise to the entire Web.
>
> Cheers,
>
> M
>
> -----Original Message-----
> From: Cord Wiljes [mailto:cwiljes@cit-ec.uni-bielefeld.de]
> Sent: 10 September 2012 11:17
> To: public-vocabs@w3.org
> Subject: Re: new itemscope or not?
>
> The schema.org specification seems to support Jeff's interpretation of the property "url" as "the WWW-address where an electronic copy of the thing that s described can be downloaded". From
> http://www.schema.org/Thing:
>
> Property: url
> Expected Type: URL
> Description: URL of the item.
>
> Only something that can be downloaded (an information resource) can have a URL. So schema.org's property "url" should only be available for "CreativeWork", not for "Thing" as it is right now. A person for example can't have a url. A person can have a website (which is an information
> resource) and this website has an url. But then I cannot find any property like "website" or "homepage" for any of schema.org's classes.
> Combined with the fact that "url" is avalable for class "Thing" (i.e.
> for everything) I suppose that "url" is in fact used ambiguosly:
>
> A book can have a url where you can download the book's text.
> A person can have a url where you find information about this person.
>
> Or in other words: "url" means something rather general: "There is a web document related to the resource that can be retrieved at this url."
> Essentially its just a "see also" to a document on the web.
>
> Cord
>
>
> Am 08.09.2012 04:14, schrieb Young,Jeff (OR):
>> If I was Godz, I would NOT assume they are the same thing. I would use
>> schema:url thusly for those decreasingly rare situations where
>> somebody (especially a remote observer) wants to describe something
>> that is honest-to-godz located on the Web. For example:
>>
>> @prefix observer: <http://example.org/observer/> .
>>
>> observer:12345 a <http://purl.org/library/Thesis>;
>> 	schema:name "Architectural Styles and the Design of Network-based
>> Software Architectures";
>> 	schema:author <http://viaf.org/viaf/26681119>;
>> 	schema:url
>> <http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm>.
>>
>> As a matter of principle, Roy's (HTML) thesis COULD be upgraded to be
>> self-describing with some hidden markup (either RDFa 1.1 or Microdata)
>> and a trivial Apache rewrite (303 redirect) upgrade to www.ics.ici.edu
>> to replace the observer URI.
>>
>> OTOH, if somebody decides that schema:url should be treated the same
>> as "itemid" (Microdata), "resource" (RDFa Lite 1.1), "rdf:about"
>> (RDF/XML), etc. then schema:url is a wasted opportunity and we (i.e.
>> the pedantic observers of reality) would need to find a new vocabulary
>> term fill this void.
>>
>> Jeff
>>
>>> -----Original Message-----
>>> From: Jeni Tennison [mailto:jeni@jenitennison.com]
>>> Sent: Friday, September 07, 2012 3:15 PM
>>> To: Ed Summers
>>> Cc: Dawson, Laura; Thad Guidry; public-vocabs@w3.org
>>> Subject: Re: new itemscope or not?
>>>
>>>
>>> On 7 Sep 2012, at 20:03, Ed Summers wrote:
>>>> It would be interesting to know if the HTML spec allowed multiple
>>>> identifiers, similar to how other HTML attributes work:
>>> "The itemid attribute, if specified, must have a value that is a
>>> valid URL potentially surrounded by spaces."
>>>
>>> http://www.w3.org/TR/microdata/#attr-itemid
>>>
>>> So that would be 'no', not according to spec.
>>>
>>> I've often wondered whether the schema.org 'url' property is meant to
>>> be synonymous with itemid. I'm not sure what happens in schema.org
>>> interpreters when you specify one/other/both/multiple urls...
>>>
>>> Jeni
>>> --
>>> Jeni Tennison
>>> http://www.jenitennison.com
>>>
>>>
>>
>
> --
> Cord Wiljes
> Semantic Computing Group
> Excellence Cluster - Cognitive Interaction Technology (CITEC) Bielefeld University
>
> Phone: +49 521 106 12036
> Mail: cwiljes@cit-ec.uni-bielefeld.de
> WWW: http://www.sc.cit-ec.uni-bielefeld.de/people/wiljes
>
> Room H-123
> Morgenbreede 39
> 33615 Bielefeld
>
>
>


-- 
Cord Wiljes
Semantic Computing Group
Excellence Cluster - Cognitive Interaction Technology (CITEC)
Bielefeld University

Phone: +49 521 106 12036
Mail: cwiljes@cit-ec.uni-bielefeld.de
WWW: http://www.sc.cit-ec.uni-bielefeld.de/people/wiljes

Room H-123
Morgenbreede 39
33615 Bielefeld
Received on Monday, 10 September 2012 11:27:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 10 September 2012 11:27:39 GMT