JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for DC-ARCHITECTURE Archives


DC-ARCHITECTURE Archives

DC-ARCHITECTURE Archives


DC-ARCHITECTURE@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

DC-ARCHITECTURE Home

DC-ARCHITECTURE Home

DC-ARCHITECTURE  May 2002

DC-ARCHITECTURE May 2002

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: rdfs:isDefinedBy (Was Re: Representing DCMI semantics as RDF schemas versus Web pages)

From:

Patrick Stickler <[log in to unmask]>

Reply-To:

This list, which supersedes dc-datamodel, dc-schema, and dc-implementors, i" <[log in to unmask]>

Date:

Fri, 31 May 2002 13:16:29 +0300

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (181 lines)

On 2002-05-30 23:38, "ext Pete Johnston" <[log in to unmask]> wrote:

> Patrick said:
>
>> I think folks are reading far too much into the term
>> 'namespace' and the relationship between namespaces used in
>> RDF/XML and the resultant URIs in the RDF graph model.
>>
>> In particular, in the RDF graph model, there are no such
>> things as namespaces, qnames, etc. Those are, of course
>> employed by the RDF/XML serialization, so that predicate URIs
>> can be expressed as element and attribute names. But the RDF
>> model uses URIs, not qnames. RDF is not XML. Namespaces and
>> qnames are not significant to, nor have representation in the
>> RDF graph.
>>
>> The value of rdfs:isDefinedBy is a URI denoting some resource
>> that defines the resource denoted by the subject of that
>> property. That's all. We don't know what the describing
>> resource is. It could be an RDF Schema instance. It could be
>> an HTML instance. It could be a PDF document. It could be a
>> portal to a relational database. We don't know. The semantics
>> of rdfs:isDefinedBy does not tell us.
>>
>> Furthermore, one cannot determine the namespace/name
>> partioning of any arbitrary URI used in an RDF graph. It is
>> not possible. That partitioning is not retained. It is lost
>> forever when the RDF/XML is parsed into the graph. Also lost
>> is the context of the qname, whether it was an element name,
>> an element-specific attribute name, or a global attribute
>> name. Cest la vie.
>>
>> The bottom line is that XML and RDF have different naming
>> architectures. XML uses qnames, which are based on pairings
>> of namespace URIs and local names. RDF uses URIs. There is a
>> rather simple, unidirectional, and lossy transformation
>> employed by RDF to get from qnames to URIs, but qnames and
>> namespaces have no meaning in the RDF graph.
>>
>> Namespaces and qnames for properties in RDF/XML are just a
>> means to an end, to serialize RDF statements and RDF ignores
>> the semantics of qnames defined by XML. Perhaps that's not
>> necessarily kosher, but that's how things are.
>
> Yes, I think I understand this.
>
> So.... _if_ the partioning of a set of terms by the association of
> subsets with distinct XML namespaces _is_ intended to carry some
> significance, and it is useful for an RDF application to present views
> of terms grouped in accordance with that partitioning, then that means
> we need to express that grouping explicitly in the RDF model in some
> way. i.e. a relationship between the terms to be grouped and some common
> resource.
>
> At the moment, I think (but I'm not completely sure!) we're saying there
> are circumstances in which we _would_ like an RDF application to be able
> to distinguish terms which in XML are associated with the namespace
> named http://purl.org/dc/terms/ from terms which in XML are associated
> with the namespace named http://purl.org/dc/elements/1.1/ ?

Well, there are two issues here, that seem to often get muddled
together.

1. What is the namespace that is used in the RDF/XML which is prepended
to the local name to generate the URI that lives in the RDF graph.

I would assert (possibly incorectly for all cases) that that namespace
is irrelevant to any use of the resultant RDF graph, and can safely
be ignored. It is just a feature of the XML serialization, but
namespaces are not a feature of the RDF model.

2. Often, a namespace is equated with a schema, or document model,
or ontology. This is perhaps understandable, given the fact that
often, coincidentally, there is but one schema, document model,
or ontology grounded in a given namespace -- but it is technically
incorrect. A namespace URI does not denote anything, insofar as
its role as a namespace. If that URI happens to also be the URI
of some resource, then OK, but that doesn't mean that the namespace
denotes the resource. Only that the URI of the resource was put
to double-use as also a namespace to provide a globally unique
partitioning for some set of names.

See my summary to the TAG for the details:

http://lists.w3.org/Archives/Public/www-tag/2002Feb/0023.html

> Is that right? If we don't need that distinction, then there is no
> problem.

We need a way to relate a term to resources which define it. And
we should use rdfs:isDefinedBy (or a subproperty of it) to do this,
but that resource is not a namespace. It might be an RDF schema.
It might be an HTML instance with prose for humans. It might be
text. Whatever.

Then, once we know the identity of that resource, we can look for
statements about the resource to determine its characteristics.
To that end, it would be good to have a standardized set of RDF
classes (or steal them from e.g. RDDL) by which to capture the
nature of those defining resources, as well as their MIME type,
character set, whatever information would be useful to an application
needing to interact with that resource.

> If we do need to make that distinction, at the moment the only means of
> doing so is on the basis of the rdfs:isDefinedBy properties associated
> with the individual terms. Is that a good basis for making that
> distinction, or should we be making some other explicit statement of the
> relationship between terms?

Well, I don't see how you can avoid making those statements explicitly,
especially since the nature of a given term may be defined by multiple
sources. Consider the case of localization labels. One may have one
RDF schema that defines the basic characteristics of the terms. But
then have additional language or locale specific schemas  that augments
the definition of those terms. And in both cases, the URIs denoting
those schemas is not in fact the same as the namespace used in the
RDF/XML serialization providing the URI of the terms. E.g.

In "uuid:8B005590-747E-11D6-9909-0003931DF47C" (core schema)
{
   <rdf:Property rdf:about="urn:foo:terms/owner">
      ...
      <rdfs:label xml:lang="en">Owner</label>
      <rdfs:isDefinedBy
         rdf:resource="uuid:8B005590-747E-11D6-9909-0003931DF47C"/>
      <rdfs:isDefinedBy
         rdf:resource="http://foo.com/docs/schemaguide.html"/>
      ...
   </rdf:Property>
}

In "uuid:BA0C6286-747E-11D6-9909-0003931DF47C" (schema providing
Finnish labels)
{
   <rdf:Description rdf:about="urn:foo:terms/owner">
      <rdfs:label xml:lang="fi">Omistaja</label>
      <rdfs:isDefinedBy
         rdf:resource="uuid:BA0C6286-747E-11D6-9909-0003931DF47C"/>
   </rdf:Description>
}

In "http://foo.com/publications/documentZ/meta.rdf"
{
   <rdf:Description rdf:about="urn:foo:publications/documentZ">
      <owner xmlns:xyz="urn:foo:terms/">John Doe</owner>
   </rdf:Description>
}

This is a simplification of a real world case. Note that in
neither of the actual schemas are namespaces for the terms
used. It is only in the actual RDF instance defining metadata
using those terms that a namespace is needed, and only because
you can't use a URI as an element name. Thus, the namespace
really has no meaning to the actual definition of the terms.

Also, it is not necessary that the URI denoting the defining
resources of a term be http: URLs. Yes, it's sometimes easier
if they are, but they need not be. I specified the example
using UUIDs to stress that what you are doing with
rdfs:isDefinedBy is identifying the resource, not necessarily
its web-accessible location.

Note also that the term 'owner' is defined by more than one
schema, as well as by some (presumably) prose document. And
that it does not share any namespace in common with them.

--

Hopefully the above is clear, and in some way useful.

Cheers,

Patrick


--

Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: [log in to unmask]

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

February 2024
January 2024
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
December 2022
November 2022
September 2022
August 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
November 2021
October 2021
September 2021
August 2021
July 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
September 2020
August 2020
July 2020
June 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
September 2005
August 2005
July 2005
June 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
March 2004
February 2004
January 2004
November 2003
October 2003
September 2003
August 2003
June 2003
May 2003
April 2003
March 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002
January 2002
December 2001
November 2001
October 2001
September 2001
August 2001
July 2001
June 2001
May 2001
April 2001
March 2001
February 2001
December 2000
November 2000
October 2000


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

For help and support help@jisc.ac.uk

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager