Re: URI Patterns (was RE: MARC Codes for Forms of Musical Composition)

2010/7/9 Antoine Isaac <aisaac@few.vu.nl>

> Hi Jeff, Martin,
>
> Interesting, your patterns look like the ARK qualifiers/variants [1], or
> don't they? That also reminds me of what is being recommended in the UK
> public sector [2].


Not sure if this has been mentioned in this thread before, but the "Creating
Linked Data" blog series by Jeni Tennison

http://www.jenitennison.com/blog/node/139

has a nice entry with an example related to the UK public sector project
approach of URI patterns, see http://www.jenitennison.com/blog/node/136 .

Best,

Felix


> It seems that some good practice could be identified here for libraries as
> well!
>
> About the problem of "some of us have multiple databases for bibs" I think
> this should not raise too many issues with the pattern.
>
> Either (1) the separation between the two contexts is purely technical, the
> data in the different databases is complementary and would together be very
> useful for one identified usage. Then it would be fair if the institution
> just created one URI for each resource. We're on the web of data, it would
> be quite a retreat from the vision if one institution in the perfect
> position for solving co-reference issues was not doing it... Trying to make
> an analogy with the "standard" web, it's a bit as if a library was opting
> for dumping text versions of MARC records on its site just because there are
> technical difficulties to massage them in a more appropriate version.
>
> Or (2) the separation between two contexts has deeper roots, reflected by
> different data being made available for different purposes. In that case it
> could be understandable that different contexts are being maintained and
> just connected together by the appropriate (sameAs/isLike/whatever)
> statements. But such a choice should be really motivated, I think.
>
> Cheers,
>
> Antoine
>
> [1] http://www.cabinetoffice.gov.uk/media/301253/puiblic_sector_uri.pdf
> [2] https://wiki.ucop.edu/display/Curation/ARK+Anatomy
>
>
>
> Martin,
>>
>> I honestly agree. People shouldn't let owl:sameAs or this discussion scare
>> them off from doing something. Individual and community understanding
>> improves and/or changes over time. Nothing is ever written in stone,
>> including identity. If people have a minute, though, they should consider
>> using umbel:isLike as a default because it is always safe, unlike
>> owl:sameAs.
>>
>> Your URI pattern alternative appears to be backward from the dbpedia
>> precedent of /resource and /page, but I get your drift. Your pattern might
>> actually closer to the truth because all URIs identify resources by
>> definition. If we admit that, though, why does the /resource segment need to
>> be in the URI pattern at all?
>>
>> Here are a couple of issues to consider:
>>
>> 1) I admit that my /marc token example was over-simplified since at least
>> a few of us have multiple databases that are "MARC". Assume, for example,
>> that some of us have multiple databases for bibs, authorities and other
>> kinds of records all of which currently start with the number 1. How should
>> this situation be handled?
>>
>> 2) We could presumably add this to your list of examples:
>>
>> http://example.org/resource/12345.html
>>
>> What if example.org later decides to support HTML variants for the MARC
>> and MODS (XML) representations you mention? In essence, this was the
>> situation we found ourselves in with VIAF. Renaming and repurposing all of
>> our resources could have been avoided if we had used a more generalized URI
>> pattern.
>>
>> Jeff
>>
>> -----Original Message-----
>> From: Martin Malmsten [mailto:martin.malmsten@kb.se]
>> Sent: Thursday, July 08, 2010 8:12 PM
>> To: Young,Jeff (OR); public-lld
>> Subject: Re: MARC Codes for Forms of Musical Composition
>>
>> This thread touches on a number of topics (multiple rdf:type, owl:sameAs
>> usage, topics vs things, etc.) which I think to a degree creates uncertainty
>> and doubt in developers that just want to "get data out there". If we could
>> capture, distill and present the range of opinions and options to a library
>> audience I think we will have helped out a great deal. It could start with
>> "Do not worry, you will not break the internet, even if you DO use
>> owl:sameAs".
>>
>> I assume we all agree, though, that institutions like libraries should
>>> conform to Web standards and thus remain relevant.
>>>
>> I'd say that usage is what hopefully makes us remain relevant. Yes, we
>> should follow the correct standards, as long as they are widely used and
>> recognized by people outside our community.
>>
>> How would you feel about these as a set of URI patterns to help libraries
>>> bridge the gap from records to resources:
>>>
>>> http://example.org/marc/12345     (303 redirect to...)
>>> http://example.org/marc/12345/   (generic resource content-negotiable
>>> to...)
>>>
>>
>> I would bridge that gap from the other side: start with the resource,
>> perhaps only keeping the record identifier. The fact that the resource was
>> initially described using something called a marc record will hopefully
>> become irrelevant.
>>
>> http://example.org/resource/12345 (uses conneg to redirect to ...)
>> http://example.org/resource/12345.marcxml
>> http://example.org/resource/12345.mods
>> http://example.org/resource/12345.rdf
>> ...
>>
>> Or just use the first URL to deliver the format requested by the client (I
>> guess that makes me a heretic too ...).
>>
>> /martin
>>
>> On Jul 8, 2010, at 10:57 PM, Young,Jeff (OR) wrote:
>>
>> Bernard,
>>>
>>> Your two quick points raise some in my mind:
>>>
>>> ·         I looked at the first example of "Correct Usages" in the
>>> "Overloading" document  but couldn't make heads or tails of it with live
>>> information. If someone could rationalize the claim of "correct usage" in
>>> this example, I might take the document more seriously:
>>> o
>>> http://ontologydesignpatterns.org/wiki/Community:Overloading_OWL_sameAs#Summary_and_Synthesis
>>> ·         I agree that owl:sameAs assertions found in the wild will never
>>> be trustworthy. I assume we all agree, though, that institutions like
>>> libraries should conform to Web standards and thus remain relevant.
>>> ·         IMO, understanding how to consume Linked Data effectively isn't
>>> as important as understanding how to produce it clearly and efficiently from
>>> information we already have.
>>> ·         My amazing argument against multiple rdf:types is more a case
>>> of being misunderstood (my own fault). I'm really not in denial of rdf:type
>>> implications of rdfs:subClassOf and rdfs:Property.
>>> ·         I think your last paragraph hit the nail on the head and bears
>>> repeating:
>>>
>>> "That said, in an open world, an application will be able to pick in the
>>> descriptions the elements it can consume. If something (someone) is declared
>>> with rdf:type foaf:Person and entailed some way to be also skos:Concept, if
>>> my application is interested in the social aspects of the description for a
>>> social web applications, I will consider only the triples with predicates in
>>> the FOAF namespace, and if your application is interested only by this
>>> resource as an entry in a resource index, using e.g. dcterms:subject or
>>> dcterms:creator, you will pick only the predicates in the SKOS namespace
>>> (prefLabel, altLabel ...)"
>>>
>>> That pretty much captures the future as I see it too. How would you feel
>>> about these as a set of URI patterns to help libraries bridge the gap from
>>> records to resources:
>>>
>>> http://example.org/marc/12345     (303 redirect to...)
>>> http://example.org/marc/12345/   (generic resource content-negotiable
>>> to...)
>>> http://example.org/marc/12345/default.html
>>> http://example.org/marc/12345/default.fr.html
>>> http://example.org/marc/12345/default.en.html
>>> http://example.org/marc/12345/default.gr.html
>>> http://example.org/marc/12345/marc.html
>>> http://example.org/marc/12345/marc.xml
>>> http://example.org/marc/12345/frbr.html
>>> http://example.org/marc/12345/frbr.rdf
>>> http://example.org/marc/12345/skos.html
>>> http://example.org/marc/12345/skos.rdf
>>> http://example.org/marc/12345/all.rdf
>>> etc.
>>>
>>> There are obviously other types of records besides MARC, but the general
>>> pattern should hold. Do you see your point lurking in there somewhere?
>>>
>>> Jeff
>>>
>>> From: public-lld-request@w3.org [mailto:public-lld-request@w3.org] On
>>> Behalf Of Bernard Vatant
>>> Sent: Thursday, July 08, 2010 5:34 AM
>>> To: public-lld
>>> Subject: Re: MARC Codes for Forms of Musical Composition
>>>
>>> Hello all
>>>
>>> Two quick points
>>>
>>> 1. Overloading or abuse of owl:sameAs in linked data land is a well-known
>>> issue that has been discussed at length, before and beyond the (excellent)
>>> quoted paper. A good account of the debate can be found at
>>> http://ontologydesignpatterns.org/wiki/Community:Overloading_OWL_sameAs
>>> Identity is a tricky issue which is representative of the discrepancy
>>> between the "hard" semantics as declared by standards, and the not-so-hard
>>> and various ones implicitly understood by the users, who tend to hack the
>>> original semantics, either because they do not read the specs, or
>>> misunderstand them, or use classes and properties not exactly meaning what
>>> they want, default of more precise ones. Use and abuse of owl:sameAs is
>>> typivcal of this. It's pretty clear that buying all owl:sameAs links in the
>>> linked data cloud to mean what the OWL specification says it means will
>>> entail zillions of inconsistencies of all kinds, the most obvious being that
>>> things considered as distinct here will be merge there. There is no way to
>>> bring global consistency to this "knowledge soup", what is needed is ways to
>>> sort it through various heuristics.
>>>
>>> 2. I'm amazed that one would debate about unicity of rdf:type at all.
>>> It's certainly a good practice for the URI publisher to declarea single
>>> rdf:type. But based on OWL or RDFS semantics, other types will be entailed
>>> even if they are not declared.
>>>
>>> for example, to keep it simple :
>>>
>>> :x   rdf:type   foaf:Person   will entail
>>> :x   rdf:type   foaf:Agent    based on   foaf:Person    rdfs:subclassOf
>>>   foaf:Agent
>>>
>>> other types will be entailed from domain declarations of properties used
>>> in the description etc.
>>>
>>> In the open world where the URI is used and re-used, linked to and from,
>>> it's obvious that new types will be acquired by entailments. And to be back
>>> to point 1, in particular applying strictly owl:sameAs semantics will bring
>>> about a bunch of possibly conflicting types.
>>>
>>> That said, in an open world, an application will be able to pick in the
>>> descriptions the elements it can consume. If something (someone) is declared
>>> with rdf:type foaf:Person and entailed some way to be also skos:Concept, if
>>> my application is interested in the social aspects of the description for a
>>> social web applications, I will consider only the triples with predicates in
>>> the FOAF namespace, and if your application is interested only by this
>>> resource as an entry in a resource index, using e.g. dcterms:subject or
>>> dcterms:creator, you will pick only the predicates in the SKOS namespace
>>> (prefLabel, altLabel ...)
>>>
>>> Bernard
>>>
>>>
>>> 2010/7/6 Young,Jeff (OR)<jyoung@oclc.org>
>>> Let me address Ross' question before attempting to argue that restraint
>>> to a single rdf:type is good practice.
>>>
>>> Here is the example in question:
>>>
>>> http://purl.org/NET/marccodes/muscomp/sy.rdf
>>>
>>> The owl:sameAs property asserts that these two URIs identify "the same
>>> thing" (http://www.w3.org/TR/owl-ref/#sameAs-def):
>>>
>>> http://purl.org/NET/marccodes/muscomp/sy#genre
>>> http://dbpedia.org/resource/Symphony
>>>
>>> The 1st URI responds with this statement:
>>>
>>> <http://purl.org/NET/marccodes/muscomp/sy#genre>  rdf:type<
>>> http://purl.org/ontology/mo/Genre>
>>>
>>> The 2nd URI responds with this:
>>>
>>> <http://dbpedia.org/resource/Symphony>  rdf:type<
>>> http://sw.opencyc.org/2008/06/10/concept/Mx4rwSmVfJwpEbGdrcN5Y29ycA>
>>> <http://dbpedia.org/resource/Symphony>  rdf:type<
>>> http://sw.opencyc.org/2008/06/10/concept/Mx4rvcNktpwpEbGdrcN5Y29ycA>
>>>
>>> Other rdf:type and owl:sameAs assertions cascade from there in dbpedia.
>>>
>>> The following document isn't authoritative, but it discusses some of the
>>> confusion surrounding owl:sameAs and may also help us sort out the issues:
>>>
>>> http://www.w3.org/2009/12/rdf-ws/papers/ws21.
>>>
>>> Here is a quote:
>>>
>>> "However, owl:sameAs does have a particular semantics of individual
>>> identity, namely that the two individuals are exactly the same and so share
>>> all the same properties." (original emphasis).
>>>
>>> Since rdf:type is a property, I assume that an OWL reasoner should back
>>> me up in my claim that Ross' example has multiple rdf:types. I just
>>> downloaded Pellet and will report on the results once I figure out how to
>>> run it. Hopefully, it will demonstrate how "share" involving owl:sameAs
>>> plays out in practice.
>>>
>>> Jeff
>>>
>>>
>>> From: rxs@talisplatform.com [mailto:rxs@talisplatform.com] On Behalf Of
>>> Ross Singer
>>> Sent: Monday, July 05, 2010 10:03 PM
>>> To: William Waites
>>> Cc: Young,Jeff (OR); Antoine Isaac; Karen Coyle; public-xg-lld@w3.org;
>>> List for Working Group on Open Bibliographic Data; public-lld
>>>
>>> Subject: Re: MARC Codes for Forms of Musical Composition
>>>
>>> My question was more based on the fact that I don't think anything should
>>> have explicitly set multiple rdf:types in there.
>>>
>>> If so, I'm curious to what they are.
>>>
>>> -Ross.
>>>
>>> On Mon, Jul 5, 2010 at 3:35 PM, William Waites<william.waites@okfn.org>
>>>  wrote:
>>> On 10-07-05 10:35, Ross Singer wrote:
>>>
>>>> Jeff, which resources have multiple rdf:types?  Of the muscomps, they
>>>> should all only be mo:Genre.
>>>>
>>>
>>> I think it is perfectly valid to have multiple types. At the
>>> very minimum everything is an rdfs:Resource whether
>>> stated explicitly or not. If something breaks when it is
>>> explicitly stated because it doesn't like multiple types I
>>> think that something is itself broken...
>>>
>>> Cheers,
>>> -w
>>>
>>> --
>>> William Waites<william.waites@okfn.org>
>>> Mob: +44 789 798 9965    Open Knowledge Foundation
>>> Fax: +44 131 464 4948                Edinburgh, UK
>>>
>>> RDF Indexing, Clustering and Inferencing in Python
>>>                http://ordf.org/
>>>
>>>
>>>
>>>
>>> --
>>> Bernard Vatant
>>> Senior Consultant
>>> Vocabulary&  Data Engineering
>>> Tel:       +33 (0) 971 488 459
>>> Mail:     bernard.vatant@mondeca.com
>>> ----------------------------------------------------
>>> Mondeca
>>> 3, cité Nollez 75018 Paris France
>>> Web:    http://www.mondeca.com
>>> Blog:    http://mondeca.wordpress.com
>>> ----------------------------------------------------
>>>
>>
>> -----------------------------------------------------------------
>> Martin Malmsten (martin.malmsten@kb.se) - Senior Developer
>> National Library of Sweden / National cooperation dept. / LIBRIS
>> http://libris.kb.se
>>
>>
>>
>>
>>
>>
>>
>
>