Re: [Crm-sig] ISSUE: representing compound name strings

n constraining them beyond the general "XML literal" datatype. An information system that understands XML literals can examine the XML and process it appropriately based on its namespace. -- Conal Tuohy http://conaltuohy.com/ @conal_tuohy +61-466-324297

Re: [Crm-sig] new technical paper

> > #E5: I think we point into an XML-RDF file. > > Yes, that's the intention, but it will only work if there is an element in > that file with attribute xml:id="E5" to act as the target for the link. > This strategy works fine for the links into the HTML expression of the RDF, > but not for the

Re: [Crm-sig] ISSUE: E74 Group (from LRMoo discussions)

> > Canada > <https://maps.google.com/?q=7141+Sherbrooke+Street+West+%0D%0A+Montreal,+QC+H4B+1R6+%0D%0A+Canada=gmail=g> > > +1-514-848-2424 ext. 5255 > > pat.r...@concordia.ca > -- > *From:* Conal Tuohy > *Sent:* May 9, 2018 1:43 AM >

Re: [Crm-sig] ISSUE: E74 Group (from LRMoo discussions)

scope of E74. > This strikes me as odd! Is it really true that the citizenry of a nation is entirely lacking in agency? Can they not take political decisions, for instance? -- Conal Tuohy http://conaltuohy.com/ @conal_tuohy +61-466-324297

Re: [Crm-sig] Properties of properties in RDF

t-forward extension > of the CRM. Any subproperty, e.g., may refine domain and range. > > All the best, > > Martin > > > On 3/15/2018 6:28 AM, Conal Tuohy wrote: > > Thanks Martin, for the link to http://www.cidoc-crm.org/ > sites/default/files/CRMpc_v1.1_0.rdfs &g

Re: [Crm-sig] Properties of properties in RDF

the-cidoc-crm, plus the > issues discussing the solution for version 6.2 (I'll look for all > references). > > Best, > > martin > > > On 3/14/2018 12:49 PM, Conal Tuohy wrote: > > > > On 8 March 2018 at 18:02, Richard Light wrote: > >> I was thinkin

[Crm-sig] Properties of properties in RDF

s://github.com/linked-art/linked.art/issues/55 along with a variety of options for dealing with the issue. In my opinion the current situation with respect to properties of properties (in RDF) is really quite unsatisfactory and could be substantially improved by a more consistent treatment

Re: [Crm-sig] P90 etc.

the "Web of Data". It can't effectively function as an "access point" (in the library science sense) without some additional context. As Linked Data practitioners, we generally have literals like "Conal Tuohy" as our source data for e.g. Appellations (and it's worth noting

Re: [Crm-sig] Domain and range of P90

semantics of P3_has_note itself are weak; a note is simply an "informal description" of something, so if I have a particular name (an RDF resource) which P3_has_note the literal string "Conal Tuohy", then I should really define subproperties so as to be able to distinguish that string

Re: [Crm-sig] Domain and range of P90

from your system > and notify the sender immediately. Do not use, copy or disclose the > information in any way nor act in reliance on it. Any information sent to > Historic England may become publicly available. > > > > ___ > Crm-sig mailing list > Crm-sig@ics.forth.gr > http://lists.ics.forth.gr/mailman/listinfo/crm-sig > > -- Conal Tuohy http://conaltuohy.com/ @conal_tuohy +61-466-324297

Re: [Crm-sig] Associative relationship mapping

omer > focus and working in partnership are at the heart of everything we do. > > > > > > ___ > Crm-sig mailing list > Crm-sig@ics.forth.gr > http://lists.ics.forth.gr/mailman/listinfo/crm-sig > > -- Conal Tuohy http://conaltuohy.com/ @conal_tuohy +61-466-324297

[Crm-sig] Blog post on mapping a museum web API to CIDOC CRM

I've written a third blog post in a series, exploring an experimental Linked Data publishing technique in which a transforming web proxy is used to transform and expose a museum collection JSON web API as RDF graphs (using the Erlangen CRM). This post deals with the challenges of mapping from the

Re: [Crm-sig] Fixity Hash in CRM Addendum

1_is_identified_by - E42_Identifier (hash value) >>>> E42_Identifier - P2_has_type - "SHA256 HASH" >>>> >>>> However, the scope notes for E42_Identifier explicitly states: >>>> The class E42 Identifier is not normally used for machine-generated >>>> identifiers >>>> >>>> A hash is definitely machine generated, so what are the other options >>>> here? Should I use a different ontology for this case? >>>> >>>> Thanks, >>>> Daniel Riley >>>> Verisart >>>> >>>> ___ >>>> Crm-sig mailing list >>>> Crm-sig@ics.forth.gr >>>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >>>> >>>> >> > > ___ > Crm-sig mailing list > Crm-sig@ics.forth.gr > http://lists.ics.forth.gr/mailman/listinfo/crm-sig > > -- Conal Tuohy http://conaltuohy.com/ @conal_tuohy +61-466-324297

Re: [Crm-sig] How to represent the textual content of documents about museum objects?

n the fly. The Linked Data resources (RDF graphs) my software produces are all based on 1 or at most 2 queries to the Museum's API, and possibly 1 to dbpedia. On the positive side, the lack of caching and harvesting makes the whole thing very simple. Cheers! Conal -- Conal Tuohy http://conaltuohy.com/ @conal_tuohy +61-466-324297

Re: [Crm-sig] How to represent the textual content of documents about museum objects?

have > structure but can't. > > Richard > > Richard Light > Sent from my phone > > - Reply message - > From: "Conal Tuohy" > To: "Richard Light" > Cc: "CRM SIG" > Subject: [Crm-sig] How to represent the textual content of

Re: [Crm-sig] How to represent the textual content of documents about museum objects?

s, rather than to promote them into being resources in their own right. But it's difficult to get a picture of which might actually be a useful approach for a Linked Data client. -- Conal Tuohy http://conaltuohy.com/ @conal_tuohy +61-466-324297

[Crm-sig] How to represent the textual content of documents about museum objects?

naltuohy.com%2Fxproc-z%2Fmuseum-victoria%2Fresource%2Farticles%2F1201 Regards Conal -- Conal Tuohy http://conaltuohy.com/ @conal_tuohy +61-466-324297