RE: working around the identity crisis

> -----Original Message-----
> From: ext Miles, AJ (Alistair) [mailto:A.J.Miles@rl.ac.uk]
> Sent: 15 November, 2004 17:24
> To: Stickler Patrick (Nokia-TP-MSW/Tampere); www-rdf-interest@w3.org
> Cc: 'public-esw-thes@w3.org'
> Subject: RE: working around the identity crisis
> 
> 
> Hi Patrick, all,
> 
> Patrick wrote:
> > Consider:
> > 
> > The URI http://swdev.nokia.com/test/foo identifies a concept "Foo". 
> > 
> > The URI http://swdev.nokia.com/test/foo.html identifies a document
> > which provides information about the concept.
> > 
> > Both share the same representation (i.e. resolving either of the
> > above URIs will result in the same octet stream).
> > 
> > However, the relationship between those two resources, that 
> > the first shares the representations of the latter, are defined
> > in terms of the property http://sw.nokia.com/WebArch-1/resolvesAs
> > rather than conneg.
> 
> I made a proposal on the public-esw-thes@w3.org mailing list 
> a few weeks ago
> for a property with identical (I think) semantics to the 'resolvesAs'
> property you describe above, 

Note that you can resolve the URI of the term to its formal
RDF description, if you're not exactly sure what it means ;-)

> to be part of the SKOS Core 
> vocab [1].  The
> actual name suggested was 
> http://www.w3.org/2004/02/skos/core#resolveTo
> although I wasn't sure if (a) that was the best name for it 

Other than having that "nasty" fragment identifier ;-) it seems
as good a name as the one we're using.

http://www.w3.org/2004/02/skos/core/resolveTo would be better.

> or (b) whether
> it was a useful thing.

We find the definition of such relationships very useful, as
it decouples what we use as generic persistent URIs for resources
from less persistent distribution URIs. This allows our primary
URIs for resources to remain "cool" while allowing evolution of
our distribution channels and solutions over time.

This approach provides IMO all of the benefit of URNs, while
providing web resolvable URIs that don't require additional
infrastructure such as DDDS, etc.

> This property was also suggested as a superprop for the
> 'skos:subjectIndicator' property which is currently in SKOS 
> Core.  The idea
> was that 'skos:resolveTo' points you to some sort of document

In that respect, the semantics of skos:resolveTo and web:resolvesAs
differ, in that the range of web:resolvesAs is simply a resource,
not a document. It simply means that one resource shares the
representations of another, and to access them via the URI of
the other resource. It says nothing about the nature of either
resource, nor about any equality between the resources (they
might be aliases, but the resolvesAs property does not assert
that they are aliases).

>, and
> 'skos:subjectIndicator' points to you a document which qualifies as a
> published subject indicator as defined by OASIS (i.e. 
> guarantees to provide
> a complete and unambiguous description of the 'subject' i.e. 
> resource in
> question). 
> 
> I would very much like to know:
> 
> (1) Do you think it is worth putting such a property in SKOS 
> Core, or should
> we just use the 'resolvesAs' prop from your nokia namespace?

Well, first, a disclaimer.

The WebArch vocabulary http://sw.nokia.com/WebArch-1 reflects
Forum Nokia's view of the fundamental web architecture. It is,
IMO, fully compatible and in sync with the latest PR version
of AWWW. However, Nokia is not necessarily suggesting that
everyone use that vocabulary as *the* vocabulary for talking
about fundamental web relations or features. It's simply what
we use to talk about web architectural issues.

Now, that said, folks are very welcome to use any of our 
vocabularies, or merely a few terms from our vocabularies,
if they find it useful.

(and using the VOC vocabulary http://sw.nokia.com/VOC-1 you
can define your functional vocabularies modularly by including
entire subvocabularies or specific terms from other vocabularies
irrespective of namespace considerations ;-)

So it's up to you whether you define your own similar term,
or use an existing term (e.g. web:resolvesAs), whatever you
feel is most optimal.

> (2) If you do think it's worth adding something to SKOS Core, 
> what's the
> best idea for a local name?

Anything without a fragment identifier ;-)

> (3) Does the property hierarchy described above seem sensible, or not?

I'm not sufficiently familiar with SKOS to answer this last
question. I'll have a look at the link you provide below, though.

Cheers,

Patrick



> Thanks,
> 
> Alistair.
> 
> [1] http://www.w3.org/2004/02/skos/core/spec/
> 
>  
> 
> > 
> > When direct resolution fails, the SWS looks to see if any such
> > relationship is defined, and if so, redirects to the related
> > resource.
> > 
> > In essence, it is a form of implementation of the PURL concept,
> > but independent of the notion of 'download location' or the like, 
> > but is defined generically in terms of the relationships between
> > resources and their web accessible representations.
> > 
> > And of course, there's no reason why this resolvesAs approach
> > cannot be used in conjunction with conneg and other methods,
> > depending on the particular needs of the system and what offers
> > the greatest utility for specific cases.
> > 
> > --
> > 
> > There are also a few interesting things to note about
> > http://swdev.nokia.com/test/foo.html:
> > 
> > * It is an information resource (see the metadata description)
> > 
> > * Its entire substance is included in the representation returned
> >   (as the creator of both, I assert that this is true)
> > 
> > * There is additional information included in the representation
> >   returned which is not part of the substance of the information
> >   resource (try to guess which bits are part of the information
> >   resource and which bits are 'extra', I bet you can't ;-)
> > 
> > Anyway, just thought I'd offer that alternative perspective...
> > 
> > Cheers,
> > 
> > Patrick
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: www-rdf-interest-request@w3.org
> > > [mailto:www-rdf-interest-request@w3.org]On Behalf Of ext Miles, AJ
> > > (Alistair)
> > > Sent: 14 November, 2004 19:20
> > > To: 'www-rdf-interest@w3.org'
> > > Subject: working around the identity crisis
> > > 
> > > 
> > > 
> > > Sorry, reposting this with a more sensible title - a 
> > discussion about
> > > working around the 'identity crisis' for http uris:
> > > 
> > > http://esw.w3.org/topic/SkosDev/IdentityCrisis
> > > 
> > > Would very much like to know what folks think of this.  Have 
> > > I just managed
> > > to redescribe some emerging consensus, have I misunderstood 
> > > anything, should
> > > I go away and read more?
> > > 
> > > I wanted to say also that I am acutely aware that alot of 
> > > people have spent
> > > a lot more time thinking and writing about this than I have.  
> > > I'm really
> > > just trying to understand this problem space, and get to a 
> > > place were I can
> > > effectively explain the issue (and the options) to other people.
> > > 
> > > Responding to Patrick:
> > > 'If you have a URI that identifies a concept, and 
> > > dereferencing that URI in
> > > a browser results in some web page displayed in that browser, 
> > > that does not
> > > mean that the URI has been used to identify two things, the 
> > > concept and
> > > the web page (document).'
> > > 
> > > I think that puts very concisely the fundamental point I was 
> > > trying to make.
> > > I probably didn't need to say any more than this.  
> > > 
> > > Responding to Daniel:
> > > 'A good solution, but I still prefer the notion of using XSLT to
> > > transform the RDF/XML definition of a concept into a 
> human friendly
> > > HTML page about it.'
> > > 
> > > I agree that, as a matter of good practise, any alternate 
> > content-type
> > > representations of the same concept need to be synchronised.  
> > > One way of
> > > achieving this would be to use an RDF/XML description as 
> > the reference
> > > point, and using XSLT to generate an HTML representation.   
> > > 
> > > Yours,
> > > 
> > > Alistair.
> > > 
> > > ---
> > > Alistair Miles
> > > Research Associate
> > > CCLRC - Rutherford Appleton Laboratory
> > > Building R1 Room 1.60
> > > Fermi Avenue
> > > Chilton
> > > Didcot
> > > Oxfordshire OX11 0QX
> > > United Kingdom
> > > Email:        a.j.miles@rl.ac.uk
> > > Tel: +44 (0)1235 445440
> > > 
> > > 
> > > 
> > 
>

Received on Tuesday, 16 November 2004 10:35:33 UTC