- From: Young,Jeff (OR) <jyoung@oclc.org>
- Date: Fri, 9 Jul 2010 14:41:27 -0400
- To: "Antoine Isaac" <aisaac@few.vu.nl>
- Cc: "Martin Malmsten" <martin.malmsten@kb.se>, "public-lld" <public-lld@w3.org>
Antoine, The UK document looks interesting, but I need to think about it some more. Regarding ARK, if you factor out the path segments they use to support their indirection mechanism, what's left are "Name" and "Qualifier". Personally, I would prefer to call these "Class" and "Instance". The UK document seems to prefer "Concept" and "Reference". SOME PEOPLE I KNOW insist on calling them "Database" and "Record". The variations go on. The essential question is whether people will still listen when you explain how this one-to-many pattern can be mapped consistently to Web standards. Jeff -----Original Message----- From: Antoine Isaac [mailto:aisaac@few.vu.nl] Sent: Friday, July 09, 2010 3:28 AM To: Young,Jeff (OR) Cc: Martin Malmsten; public-lld Subject: Re: URI Patterns (was RE: MARC Codes for Forms of Musical Composition) 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]. 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 > > > > > >
Received on Friday, 9 July 2010 18:42:00 UTC